World: r3wp

After extensive testing, I've come to the following conclusions about 
the View facets I mentioned before:

	type		; required, but not used by View directly
	span		; required, but is depreciated / not used
	data		; used by VID styles
	saved-area	; used by View
	line-list	; used by View
	action		; used by VID feel system


So, if you create a View-only GUI I believe you can safely use / 
redefine the following four facets: type, span, data and action.

Which leads (sort of) to my next question. Does anyone think it is 
worth developing a simple, high-performance, low-memory GUI alternative 
to VID? The aim would be to have it built on View from the ground 
up such that you could (for example) use enface / rebface (or equivalent) 
without needing %view.r (and the over 120 KB of mezz it pulls in). 
If there's sufficient interest I'll document and release the Alpha 
implementation I have.

Yes!

I've built GUIs from hand and when the whole GUI is built by hand, 
I found it to be considerably faster and much lighter on the memory 
usage.

How much does your  low footprint GUI improve on the memory usage?

I think it is a great idea - after all - wasn't VID just something 
to get the ball rolling and show the rest of us how we 'could' do 
things?

yeah .. except there are only a few people able to "do" things :(

I'm working on it, I'm working on it :-)

That would be great Ashley.

As Brock said, VID is an example. Carl will be interesting to see 
an alternative too ! So am I.

Ashley, have you checked out Steel much ?

Uhm...  GLayout uses VID...

Oh ok, I see.

I thought Steel was not going to use VID though .. and Glayout was 
just a temporary and unsupported thing

No it doesn't Ashley, read again.

Ashley, if it is really simple, I would love to see it.  In programming 
I sometimes have to "reinvent a wheel" in order to be able to understand 
how that wheel works so that I can use it.  A simple wheel makes 
it easier for me to grasp the concept.

Sounds like a good idea. Especially to better support data-form like 
GUIs. Together with Cyphre I have made such a dialect. We could take 
some ideas from it.

Ashley, it's a good document, separating the View and VID attributes.

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