World: r3wp

layout is a translation stage ...  this is not usefull you lost CPU 
time and memory for not a real gain ;)

RebGUI is really nice attempt and only few styles are missing from 
general well usability ...

When I was working on MDP-GUI some month ago basing me on the very 
first intent of ashley we were using a layout compositor (and a layout 
call) to renderize the docuement view than Ashley comes with a design 
based on pre contructed minimal enherited face system and using only 
show the gain inthe do view area rendendering process was about 300 
%:)

I don't understand what you mean by "constructed minimal ...."

so the actual RebGUI is the soon of the work and research of Ashley 
on the MD-Viewer program ;)

my-face; make face [ font: [color: black] ] text: none ]

for example

p: number: bullet: bullet2: bullet3: make face [
			size: as-pair page-width 1
			color: white
			edge: none

   font: make font [size: font-size offset: 0x0 align: 'left colors: 
   []]
			para: make para [origin: margin: 0x0]
			feel: make feel [
 				over: func [face act pos][
					feel-face-docs: 'docu
				]
	 		]
			state: none
		]

		©: make p [
			font: make font [size: to-integer font-size * .75]
			para: make para [origin: as-pair 0 para-indent]
		]

		define: make p [font: make font [style: 'bold]]

yu have some primitive object based on a father object (make face) 
 and then there sons inhert and enhance there capabilities

how is that different from layout? Layout parses your VID code and 
creates View face level one ...

but once you apply layout, you can't get back and decompose to VID 
code ...

so you have 3 levels of inherence in this case face -> p -> @ or 
define

actually it is possible to decompose a face to any dialect, it's 
just not built in and an exercise for an expert. ;-)

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 ;-)