World: r3wp

Graham: It's *Alpha* so no hard benchmark results yet, but moving 
from VID to View for mdViewer cut the WinXP process size from 15MB 
to 12MB and improved speed threefold ... I'd expect similiar things 
from a View-based GUI.


Anton: "No it doesn't Ashley, read again." - I thought the opening 
paragraph of the referenced document made it pretty clear; "Facets 
are attributes of a face. Facets include the face's location, size, 
color, image, font, style, paragraph format, rendering effects, behavior 
functions, and other details.", but I'll probably use the term attributes 
anyway as facets might be confused with faces.

Louis: Good documentation can make *anything* seem simple! ;)


Robert: Maybe. Main purpose of a View-GUI is for high-performance 
scripts where you really want to know what *every* face is doing.

By golly, Ashley, you're right !  That's the end of my confusion. 
But it's easy to be confused - see section 6 of the same document.

(I confused "facets" with "style facets")

Ah, that explains it. No harm done. ;)

sorry for doubting you :)

RebGUI (alpha) and draft documentation available at http://www.dobeash.com/it/rebgui/


Only a few basic widgets defined at this stage, so don't try and 
convert your VID layouts across just yet! ;)


Being an alpha, the design is still settling down so feel free to 
question anything that seems wrong. If there's sufficient traffic, 
feel free to start a RebGUI group.

Or just grab the source (and run %test.r) directly from http://www.dobeash.com/files/RebGUI-010.zip

Ashley, since you have separated the View and VID facets, does this 
mean that RebGUI can work closely with VID, without the two affecting 
each other ? Eg. could faces from a VID LAYOUT be moved into a RebGUI 
DISPLAYed layout, et vice versa ?

Nice demo. It works straight away after unpacking.

I wonder why you impose a minimum window size. Why should the user 
not be able to shrink the window if it is desired ? Shrinking the 
window may hide some of the (less flexible) widgets, but also reveal 
content of other windows behind this one.

It was not immediately clear to me, from the DISPLAY help, whether 
ORIGIN-SIZE was referring to the window offset or the initial layout 
position within the window. Compare to LAYOUT/ORIGIN.  Actually I 
was probably confused because I was expecting something similar to 
VIEW/OFFSET...

Nice web page, by the way.

In http://www.dobeash.com/it/rebgui/facets/for the CHANGES facet, 
you can add OFFSET to the list of flags (this is how you can take 
advantage of hardware scrolling, if supported).

A suggestion for PROGRESS style, it can be implemented nicely without 
using a subface, using only the effect block to draw the bar. (I 
have made such a style, in order to make it iterateable in a list).

for the CHANGES facet, there is the TEXT flag too. It's for changing 
a window title without unview-ing the window. ie (from %analog-clock.r):
l/text: mold now/time 
l/changes: 'text 
show l

how can I refresh a layout while i'm resizing it ?

can I insert a show in it ?

actually when I resize a layout by clicking left mous button and 
pointing to one of it's borders I have an ugly thing

how can I do to insert a refresh action while the border of the layout 
are deplaced

you can do it at 'resize event, but i don't think you can do it during 
the resizing

Vincent I yet do it on resize event completion but it's during the 
completion of the resize event I need to have the refreshing to polish 
the UI eatch time the mouse pointeur is moved ..

event system is stopped when you resize the window: try to do something 
at each clock tick (at 'rate speed,) and you'll see that no event 
is processed while resizing

I know that but there is no matter to plug a little refresh code 
during the resize completion ?

sorry, even busy loop are stopped. no code execution while resizing: 
when you start resizing with mouse, all executed code stops, when 
you finish resizing, code resumes and an event 'resize in generated. 
So no refresh during window resize or movement (white background 
visible, truncated display, and others glitches), but only after.

k thank you :)

well  there is no posibility to refresh within the resize event  
in VID but we can ask carl to add this kind of tricks into VID process

Ashley, is the intent that one develop first in VID, and once finished, 
recode in Rebgui?

Graham, that doesn't make any sense.  Why would you do that?

I looked at the example and the references are hard coded ..

so, if you add another face, you have to change all the references 
by hand if the ordering changes.

So, I presumed that you prototype first in VID and then optimize 
in rebgui

II think that's from a minimalistic POV.  If you're still learning 
View then perhaps you should use VID to prototype and explore your 
styles and then just move the values that you need into a style definition 
for RebGUI, however, if you are a seasoned expert such would not 
be necisarry...

:)

Changing references in a file by hand can be really simple too, Find/Replace. 
;~>

say you have 20 odd faces, and you insert one in the begining .. 
then that's 20 references have to do a find and replace on ...

rebgui seems incompatible with /View < 1.2.10 (crash)

Then you aren't talking about references within the styles but references 
to the faces from outside the top level face, right?

If you're talking about styles then the only way I can see that happening 
is if you are building something like a text-list but then you should 
be using itterated faces which elimates the problem.  If your talking 
about referencing the faces from elsewhere in the code then I disagree 
110% with the idea of not using a word to reference the face, but 
then we're just talking about convention too and you're free to reference 
values pretty much however you like. That's the power of REBOL!  
;~>

Oh, and Ashley, good work BTW! ;~>

yes very good work ;)

can we initiate a contest to create styles (widgets) for RebGUI ?

AShley is one of the few VID artist ;)

one of the first widget that I want to work on is a status bar that 
can encap text, progress and the resize logo

good work Ashley!

- changing the "foreach [style facets] spec" loop in display.r to 
something like "parse spec [any [opt [set varname set-word!] set 
style word! opt [set block block! (...)]]" would allow the use of 
"return" in place of "return none" and let users to define var names 
for faces in definition block.

- found the problem with /View 1.2.1 : i did define 'as-pair as func 
[x y][add 1x0 * x 0x1 * y], and it crashes here, but it works with 
as-pair: func [x y][to-pair reduce [to-integer x to-integer y]]

VID is great for prototyping, and for apps where saving a little 
memory and speed aren't critical. So, I think VID is still a valid 
prototyping tool because you don't know what you want to build the 
first time out (in many cases) and it allows you to play around more, 
with less effort. Now, there's no good reason you couldn't use the 
VID dialect, limit yourself to what REBGui can do, and use the VID 
spec to generate REBGui code. Best of both worlds.

RebGUI 0.1.1 released ( http://www.dobeash.com/files/RebGUI-011.zip
) and View facets documentation updated from feedback ( http://www.dobeash.com/it/rebgui/facets/
).

Anton

 1) VID working with RebGUI ... no reason why not (haven't tried it 
 yet though)
	2) display help cleaned up
	3) Minimum window size ... can be set to 0x0 with /limit

 4) Progress bar using effect ... agree. I want to emulate the WinXP 
 progress bar with image / effects

Graham

 1) Intent ... Ammon & Gregg answered this already; bottom line - 
 whatever folks feel more comfortable with

 2) Positional references were only meant to be for sub-faces of a 
 widget ... documentation corrected
	3) display now accepts set-words as per Vincent's code

Vincent

 1) Changed all occurences of as-pair to to-pair so your prob is fixed 
 (and RebGUI can now run from rebface)

 2) Change 'foreach to 'parse ... done (with the benefits you listed)

Shadwolf

 1) "Ashley is one of the few VID artist" ... thanks, but I defer 
 to Chris in all matters graphical! ;)

Gregg
	1) Agreed. (Need I say more? ;) )

Out of interest, I started rebface (REBOL/SDK) and did several recycles 
before looking at its process size under WinXP. Did the same thing 
again but after do'ing %styles.r and %display.r, and repeated the 
procedure for %view.r (the SDK func that pulls in VID). Results were:

	rebface	3,540 KB
	RebGUI	3,628 KB
	VID		5,224 KB


So I can say that (at this early stage) RebGUI seems to use 88 KB 
while VID uses 1,684!

I guess we will have to see what happens with the use of more complex 
faces

Ashley, I don't mean to undo your work, but perhaps it is easier 
to add a compatibility layer for functions missing from older releases? 
eg.
if not value? 'as-pair [as-pair:  <insert source as-pair here>]

That will shrink your code and user code down a bit.