World: r3wp

the idea of having Hidden face is to be able to use the a face as 
test device but without calling the rendering engine and the contructor 
so not using alot of resources just for a not displayed face

that would be done outside the current window face and should not 
need any tags for that.

henrik yeah indeed I wasn't planning to keep cheating around for 
ever that's just a hacing temporal solution in the case of  area-tc 
develpement. That was to provide you an exaple of use of an hidden 
face

yes, ok :-)

Ok here another example imagine you  are processing video stream 
 you can use hiddent face to prepare content to be displayed  en 
then swap the faces

I hope Henrik is convinced now, especially because of  the good tab-panel 
example :)

steeve yes tab panel with the ability to set up your colums to be 
display is important way to use hidden face (gob)

hidden face + multi tasking thread in video application can be really 
great to smooth things

yes, will look at HIDDEN.

Does anyone know where in VID34 the entry to the face-tree is? I 
saw that win-face is set in VIEW but can't find any reference to 
it.

And I don't find my set-words I used in the VID spec block.

I embarrassingly forgot where it is. :-(

set-words are found in window/data/faces/1/names, where window is 
your window gob. Not meant to be like that, should be accessible 
by an accessor function.

Oh, I've just found that particular accessor function already in 
%panel-access.r, called GET-PANEL-VAR:

window: view/no-wait [test: button "Test"] 
button: get-panel-var window 'test

in the R3 console, when typing:

? do-

Does 'do-style turn up in the list?

No. And that's after LOAD-GUI.

Why is DATA not shown if I just enter: window?

It's hidden?

yes, some GOB attributes are not shown.

which is why I was wondering about reflection functions on GOBs not 
working before.

Henrik, if you are concerned with making the code modular, it might 
be a good idea to stick with the .r file extension for now.

it's quick to change, but Robert's dev environment is set up for 
.r3 for now.

I use hidden panels and buttons all the time .. to reduce GUI clutter. 
 When the user does something that satisfies some condition, I then 
show these hidden buttons, panels.

Other systems use ghosting to achieve the same benefit

there would be a difference between disabled and hidden items.

hidden is invisible disabled

yes, it could be that

i read an article stating that the 2D acceleration on windows seven 
was really poor

I reworked the traversal code. It should correspond now to the diagrams 
on the implementation page on the wiki. It's also much easier to 
read.

Do you have tooltips in this gui?

I think an hidden item should not be disabled by default (allowing 
"ghost" validation).
I you want both, then add the both flags HIDDEN + DISABLED

i mean it should accept some events event if it's hidden

*even if

what sort of events?  resize ?

VALIDATION

required for tab-panels

When you switch of tab and hide some sub-panes, then when you validate 
the whole screen, you need to validate event the hidden ones

if they're hidden you can't correct them if they fail validation

why not ?

just show them if validation fail

changing of state is a dynamic behaviour

Hidden faces should still be accessible programmatically, but can't 
get focus or key events, including access keys.

To clarify, depending on the event loop model, you may be able to 
post messages to them, but the standard UI event loop won't.

exact

graham, tooltips will come. I'll add them to the spec.

Don't make the UI depend on tooltips too much - they aren't supported 
on touch screen UIs, and those are becoming more popular.

Well, that's an app decision not a framwork one IMO. Designing for 
touch screens looks different in a lot of aspects anyway.

to my mind a tooltip should be an HIDDEN widget you add or not in 
a panel. 

This widget would "sense" the move events in its parent container 
and decide by himself if he must  pop up or not.

Framework design can shape app design. For a new GUI framework, it's 
best to support a variety of interaction models. There are a lot 
of apps written on legacy frameworks that are having trouble adapting 
to the current interaction models. For instance, we better assume 
that there can be more than one simultaneous input - multitouch is 
here already.

Does r3/view support multitouch?