World: r3wp

Pekr layout is a dialectal parser so he treat the key work (consoming 
CPU and if you have a lot of widget to renderise like into a MD view 
area or a list it's a nightmare...) and the used widgets are the 
VID default ones with lot of unneeded thing ...

words ...

key words not key work ;)

how is that? Even with VID, you can set facets to 'none, if you don't 
need them. And layout is involved only during parse and VID decomposing 
phase, not later, so imo only time it takes is to initially parse 
and build View face level hierarchy, no? Then there is imo no difference 
from RebGUI.

a: box 300x300 ... a/pane: layout heavy-list-of complicated-widgets 
and a: box  ... insert tail  a/pane tiny-widget then show a are not 
the same

when you work with layout you have a loop that create in the VID 
dialectal compliant way the futur content of a/pane then you have 
a second loop (layout) that treats the VID dialect content of you 
temporary object to insert the result into the pane and then you 
have show that draw on screen what you have on the box/pane buffer 
;)

Petr, I think RebGUI is faster because it's not concerened with styling 
schemes as VID does; it's benefit is that it's doing less than VID 
always tried to accomplish but never fulfilled as much as it would 
take to call it complete.

using premade face you avoid the compositing of the VID layer you 
fill the pane field and realize it on scree with show ( so you have 
2 loops intead of having 3 loops using the layout methode an once 
again layout is good for tiny composed interface but for complicated 
interface that's a too long way to do  ;)) )

Chris RebGUI is faster because you don't use layout parser ;) what 
does layout ?

it takes what you write in VID  and convert it into face  based object 
... RebGUI skip this stage and works directly with the objects ;)

VID  use a translation process and REbgui on use it once to make 
the window first design but then not any more for the design ;)

of internal widgets

interna to the window ;)

Yes, that's what I meant: But VID wouldn't need a layout parser, 
too, if weren't as stylizeable than it is. As far as I know, RebGUI 
*by design* doesn't support different styles and therefor is by design* 
faster.

That's a different approach with different goals in mind.

Ah, Shadwolf, you don't use Layout but you use Display which is Yet 
Another Dialect. ;~>

and easier if you "only" need a tradition GUI ?

And I very much appreaciate the RebGUI efforts.

yes but when you manipulate in VID you are very tempted to pass by 
stylize/master you premade object then put them with the good args 
into a buffer then renderize the buffer using layout and show ;)

Ammon yes but display is a concatenation of view/new layout  ;)

so you use it once

you can do a: box ... than a/pane: display [subwidget organisation 
] there is no need to do that

because you have the insert tail a/pane [ object widget not dialect] 
show a capability :)

ichris I'm not sure that we can't make using rebgui sharper things 
more styles or even skinnable that's not the primary goal in fact

ashley's roadmap is 1) the engine and widgets list edicting 2) the 
bettering of those widgets but you have to keep in mind that some 
widgets are process consumer and you can't reasonnably expect user 
to wait 3 minutes before having on screen there datas :)

Yes, that's the good thing with RebGUI: completeness over fanciness 
;-)

Hum I don't think the one is the ennemy of the second  ;)

But it's far easier to accomplish in that order ...

you can have fancy things as soon as the basement and the whole system 
design allow it without impacting on perfs ;) But that's a true design 
effort ;)

but it's important to have people working on fancy to bring us idea 
and maybe find better way to achieve the fancy effect wanted ;)

I'm absolutly convinced that draw/AGG capabilities open to us a true 
amazing scope of posibilities

We have Cyphre for that   :D   
Have to leave now, sorry, so bye for now!

bye talking later I have to go too ;))

bye :)

I still think what you basically say here is not all that true. Layout 
loop is involved only during composition, then, once on-display, 
you are at the same league with VID as well as with RebGUI, more 
or less....

pekr make the try take a very frirst version of MDP-GUI and take 
the lastest  You will be suprise ;)

Hi Petr, hi shadwolf. Back agin. Petr, just FYI (and mine, too) I 
had a quick look: MOLD/FLAT makes 43 KB from my source file, COMPRESS 
MOLD/FLAT leaves some 9'500 bytes ;-)

Yes, Petr, if you use VID correctly, you setup your UI *once*, and 
this must done either way. That's why today's apps often have a long 
load time and entertain the user with a splash screen.

I think I will file a bug - that is not normal, or I just don't wish 
it would be normal - Rebol really can't block system buttons during 
its internal activity. That is weird, imo wrong and annoying.

the same goes for resizing - it redraws screen only when you finish 
resizing your window - no other app does that ...

but resizing when moving should be very slow with complex GUIs

dunno - I just state what I find. Others do it ...

resizing issue is rather cosmetic to me, but that "blocked" UI is 
really annoying ... Rebol shold be more async ...

btw - at home I have 4 icons on the left desktop side, here at work 
only 3 - rebol.com, local and console. How is that? IIRC the fourt 
one is Public. Maybe it is because I set my public files to c:\rebol\view 
and not specif user account?

another cosmetic issue - I was offered to update when I ran older 
alpha and it used old buttons, whereas whole Desktop uses btns ...

tools/font lab uses old buttons too...

that is tool, but I talk about Desktop functionality. It offers you 
auto-update dialog. btw - it should ask if rebol should check for 
new updates imo - settings in preferences panel ...

try Rebcircle demo ... then press mouse button and move, to generate 
more events - 10x faster :-)

... while Cyphre demo, using the same principle, nearly stops .... 
strange ...

no, that's not the same principle, in Cyphre demo I used "engage: 
func [f a e][switch a [time [something]]]....." so it renders ONLY 
when time-event comes, in Rebcircle is "engage: func [f a e][something]...." 
so new image is rendered on every event.