World: r3wp

*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.

Modules are not utilized yet, because the model for them isn't done 
yet. The GUI is serving as a test case to help refine the model. 
This is exactly what needs to get done in order to finalize modules. 
Once we have modules we can get plugins.

This all sounds good. We do some real things, and they define new 
requriements or shape our opinion on other things ....

Henrik - so my words were fulfilled, when I claimed, that you can't 
cover all possible visual states of style by just one draw block 
and its parametrisation via facets :-) This is "frames" model of 
some kind, no? But if I understand it correctly, you do it only when 
you need it, so still not vasting space?

Not really the frames model, but otherwise you are correct. The capability 
to do this was already in the new model - Henrik's work just prompted 
the creation of some helper code to make it easier to do. We're still 
using the new model.

Could you please elaborate a bit, how is 'fly transition effect being 
done? Is there any concept for transitions in general, or is it just 
one effect, which will be possible and is "hardwired"?

I haven't fully examined the transition model, but the fly effect 
is an addon. It is hard coded, but not any more built in than a style. 
You should be able to add your own transitions.

An important aspect of the multiple draw block model was that it 
took Carl around 5 minutes to add. So it's pretty simple to change 
the system if he wants.

what's exactly the advantage to handle several draw blocks in a style, 
could you give an example ?

Steeve:
http://rebol.hmkdesign.dk/files/r3/gui/101.png

The vertical and horizontal slider are two different draw blocks.

do u mean it's the same style ?

yes, the orientation is determined by the size you give it.

anywayn your styles are cool

thanks :-)