World: r3wp

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.

thanks for explanation. I tried to add rate field, but it changed 
nothing ...

there's "to image!" and it's 600x600 pixels so I think it's REBOL 
redraw speed limitation...

Pekr: for different bookmark icon (left bar in desktop), there is 
a "Reset bookmark" script in the Rebol.com/tools folder. See Carl 
advice in the note of this release http://www.rebol.net/notes/rv13-changes.html#section-3

Now that we have 1.3 - any idea on when we get the SDK and Command 
builds?

Soon.

I wonder if IOS will be regenerated for customers too?

Soon again.

OS X!!

cool! I was afraid I will have to use old knowledge for IOS .....

New Qt - the stole our originally planned design for buttons - http://qt4.digitalfanatics.org/articles/images/rc1/qtrc-3.png

the ones made by Chris were really nice (nicer than current XPish 
ones)

http://qt4.digitalfanatics.org/articles/rc1.html

AGG based app - nice :-) http://www.epsitec.ch/cresus/documents/base-f.php