World: r3wp

Of the 25 View facets, I have been able to prove (via simple test 
cases) that 19 are used in some shape or form; which leaves 6 that 
I cannot prove are used:

	type		; view make face [type: 'blah] works just fine
	span
	data
	saved-area
	line-list
	action


For the record, passing an empty  face to 'view changes the following 
facets:

	text            string!   ""
	old-offset      pair!     0x0
	old-size        pair!     100x100
	face-flags      integer!  1


and doing a "view make face [pane: make face []]" will additionally 
set the sub-face's 'parent-face facet.

Oh for some low-level documentation!!! ;)

'line-list is only used on "long 'text" face (more than 200 chars 
IIRC). Be carefull with it.


'span was used in View 1.2.1 to set a pixel ratio (zoom) between 
'offset, 'size and correspondng real screen values. I think recent 
beta/alpha does not care of it.

'saved-area is considered if  value is 'true IIRC.


'action is checked by 'feel function, so can be used if 'feel does 
not care of.

'data depends of  'feel too.


'type could be used. Only 'layout or other VID functions use it AFAIK

By the way, the words in a face object are not "facets", as I fell 
into believing some time ago. Facets are a style's dialect words 
which follow the style word in the layout block. eg. layout [BUTTON 
"hello" red [print "pressed"] ]    BUTTON is the style word, the 
rest that follow are the facets. These may or may not translate nicely 
into attributes in the new face object created for this button. A 
single facet could affect several attributes inside the button face.

How can I minimize a View window to a tray-icon only?

This I grabbed in Dec 2002
Rebol [
	title: "little custom tray exapmle"
	author: [cyphre-:-seznam-:-cz]
]

set-tray: does [
set-modes system/ports/system [
	tray: [
		add main [
			help: "Just some help line"
			menu: [
				desktop: "This is my tray"
				bar
				test: "test item"
				bar
				quit: "Quit"
			]
		]
	]
]
]
system-awake: func [port /local r][
    if all [r: pick port 1 (r/1 = 'tray)] [

        if any [(r/3 = 'activate) all [(r/3 = 'menu) (r/4 = 'desktop)]][

  view/new/offset layout [banner "you clicked the tray button 1"] random 
  200x200
        ] 

        if all [(r/3 = 'menu) (r/4 = 'test)] [view/new/offset layout [banner 
        "you clicked the tray button 2"] random 200x200]
        if all [(r/3 = 'menu) (r/4 = 'quit)] [quit]
    ]
    return false
]
system/ports/system: open [scheme: 'system]
append system/ports/wait-list system/ports/system
system/ports/system/awake: :system-awake 
set-tray
wait []

Do that, then look to your system tray for the rebol icon.

Thanks, I try it.

Anton, http://www.rebol.com/docs/view-guide.html#section-15seems 
to contradict you. ;)

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.