World: r3wp

Are we any closer to "more ppl being involved"? :-) It is few more 
weeks from such statement. Not being impatient, just asking .... 
it seems that there is still major design work being ongoing, and 
now it is dialogs ....

dialogs are nice (although I hate them as a concept :-), but the 
most important for ppl will be lists - tex-list, list, grid, tree-list. 
Those are more complicated style, and highly expected ones (looking 
into blog comments). At least one of those styles should be tried 
to proof the concept. So far the most difficult style which was build 
seems to be scroller (area)?

Question to BrianH probably: does current design allow "iterated 
faces", like in VID2?

I think there are a few more problems to solve right now, before 
we can get more people on board, otherwise there would be too much 
noise.

Pekr, I think iterated faces are gone, which is a good thing.

Minimalized faces and the gob model are partly designed to make iterated 
faces less necessary. We haven't needed them yet.

Re-did scrollbar for the third time. It gets easier every time. :-)

the subject that worries me the most is how is managed the caret 
handler

I have not studied that, and I don't think that part is complete 
yet.

I fear that this is not done better than in R2.

so that we can't mix and edit easly draw blocks wich contain text

i hope i'm wrong

all depend of the efficientness of caret-to-offset/offset-to-caret 
functions (or their equivalent).

if the can deal with richtext block or draw blocks, we are daved. 
If they can't it will be ever a mess to build richtext editors.

*we are saved (not daved)

From Parse: Scrolling panels was greatly sped up a couple of days 
ago. I noticed some extra refinements to some internal updating functions 
to omit excessive redraws.

cool. Henrik is probably referring to my parse group post, stating 
that public alpha button-colors.r scrolls rather slowly ...

most slowdowns are because of excessive redraws, so as we move along, 
those are weeded out and the GUI speeds up.

redraws are caused by VID, or you mean excessive redraws non optimisations 
in View engine itself?

non-optimisations

oops, misread that sentence

redraw slowdowns in VID of course, but they are due to non-optimisations 
in VID. :-)

My sentence is english wise confusing in itself, so :-) hmm, I thought 
that redraws, correct clipping (decision what needs to be drawn and 
what not), is View's job. IIRC we have some helpers in View2, via 
'changes field or so ...

Do we have something like PUSH/POP for draw, or low level caching 
of pre-rendered stuff?

Yes. And it's all turned off right now. :-)

So we have it, and it is turned-off? :-) Why? :-)

Basic rule of programming:

1. Make it work.
2. Make it work fast.

:-)

1.5: Make it work correctly

3. Make it bloated

Maarten;  Not to purposely pollute the REBOL3 discussion; but isn't 
rule 3, a Rule of Management?  Not something Carl (fortunately for 
us, or many rebols come to think) prescribes to.  Anti bloat being 
part and parcel of our long winter of wait for REBOL/3?

Yes, new VID starts being bloated. It went from 13KB compressed to 
22KB so far, and I start to think of buying new harddrive because 
of it :-)

Bloated is the opposite of working correctly, as a clean design is 
one of the design requirements. So, 1.5 negates 3 :)

Maybe Maarten meant it the other way - simply put - first things 
first. If Carl would design it with the whole VID scope (focusing, 
many other styles, adding other subsystems from the very beginning), 
the design could be shifted, and hence bloated?

When I spoke about addition of some other subsystems, I simply meant, 
that for the release (not the development phase), we can't afford 
to do the same mistake as with VID2 ... but so far, even when I am 
judging only from what info is available, I think that VID starts 
to shape nicely ...

I don't know why Carl needs to work on a VID3.  Why not just release 
and distribute VID as an addon.

The plan is to get the core concepts and infrastructure done, make 
enough core styles to make sure the infrastructure works and make 
DevBase, and then let the community bloat it with their own styles 
at their option. Modularity means that we don't have to ship a monolith 
anymore.

BrianH: what Paul probably means, is why VID, why not Core .... but 
this one was debated to death here .... many ppl might not agree, 
but that is the only thing we can do about it ...

Where do you think the PARSE improvements are coming from? We are 
working on Core, because Core isn't good enough now to implement 
the new GUI. There have already been significant enhancements to 
the core as a result of the GUI work.

In that case BrianH, then it doesn't sound like just VID is at work 
here.  Sounds like the underlying VIEW component is still under development.

Any talk of timeframes?  I know that is usually a sensitive subject.

... as for me, I like View, so I am OK with it. But as I already 
said - imo after the VID, Carl should return to Core, to get it to 
beta releasable state, and upload host source codes to DevBase, as 
promissed. I am for less functionality for 3.0, but beta code. Untill 
that happens, Carl is the only one working on R3 ...

I think noone will provide you with any timeframes. But, I read somewhere, 
that soon (whatever that means) there will be more ppl included in 
testing of VID 3.4

I plan on having a very robust development effort once we get a beta 
release.

No, not just the underlying View component, low-level system enhancements 
and even mezzanines that can be used for non-graphical development 
- Core changes. The work on the new GUI is generating benefits for 
people who don't need a GUI.

That is very good news Brian.

I don't use GUIs at work except for web-generated ones, so I am very 
concerned about Core :)

BrianH: but that is "coincidence" or simply side effect of VID development. 
What Doc and others had in mid was "real" Core development - modules, 
plug-ins, tasking/threading, devices, networking, etc. But - let's 
finish VID now, and move to something else ...

Of those you list there, only modules are getting some love as a 
result of the GUI work so far, as the GUI will be modularized. However, 
the new GUI will be used to implement the new DevBase, and that will 
bring us open source code and more people.

There is some basic module functionality in R3 alpha already, isn't 
it? It is cool, if modules are starting to be utilised ...

I think we're doing pretty well on catching bugs and getting things 
redone and simplified that are too hard to work with. Carl needs 
a lot of convincing in this department, and will ask me if there 
isn't a different way to do the same thing. He needs convincing that 
his code or methods are too hard to work with, but when there is 
a change, it's usually a great one, such as the recent addition of 
multiple draw blocks for the same style.

So I think he will want to interfere, unless it's a component that 
I wrote that works flawlessly, is perhaps 4-5 lines of code and I 
didn't mention any problems in developing it. :-)


We're two people catching bugs a little faster than Carl can fix 
them. When the situation becomes opposite, then probably there will 
be another release or more people added.

Having seen this development process up close, shows me that it's 
really important to get core changes for VID done now, because it 
will be a lot more difficult to fix that later.