World: r3wp

HIDDEN could be used in some view where some data must not be showed 
(dynamicly) to some users.

depending of user's rights

Would it be wise to have hidden faces that way? it would be easy 
to find the face information anyway through the console.


There is another area, where it might be useful, but not sure: Tab 
panels, which hide entire panels of faces.

Agree but all users are not developers, (they will not peek in the 
console  ;-)

BY combining INACTIVE + HIDDEN you can have several  views of the 
same Panel.
Detailed ones and a shortest ones.

well, I think we want realistic use-cases for each tag. HIDDEN might 
be useful in the context of "don't render this as it's hidden, it's 
a waste of time"

yes, it might be useful there, but it seems that INACTIVE would be 
enough along with the original DISABLED. INACTIVE is what I call 
FROZEN.

In my version, DISABLED remove completly the face so that it's not 
constructed or  activable anymore

yes actually your FROZEN is the same as INACTIVE

Another usage for the HIDDEN state.

To add a validation process not associated with something to show.

For example, a component to check the rights of the user at the validation 
of a pannel.

Though, something like handling the rights should be server sided

My original DISABLED allows the face to still be rendered in a disabled 
fashion, which is good for forms. I'm not sure how useful it is to 
have your DISABLED after initial rendering, because you would actively 
have to remove the face.... although that presents some interesting 
possibilities for altering the face topology. There are already styles 
in R3 that don't render and that's handled differently.


The idea for FROZEN was that it would be a first step toward using 
the same styles with altered behavior for a GUI editor. FROZEN was 
selected, because of the simple FREEZE-FACE/THAW-FACE names.


READONLY seems the same as SELECT, but READONLY is probably a better 
name.


HIDDEN seems like a cop-out to me. :-) If you want a security measure, 
elements that a user should not see should not be included at all.


With my DISABLED, FROZEN/INACTIVE and READONLY, would that cover 
it?

Let me think... I have to find a better usage for the HIDDEN state 
:)

keep at it :-)

About my DISABLED it's true that i'ts only usefull at the construction. 
I.E When You want to construct a pannel from an existing one.

But it implies some inheritance capabilities, i don't know if it's 
possible currently

template panel?

About HIDDEN, your example of a multi TABS panel is good

all the fields (even the hidden ones in other sub-panes) have to 
stay activated because you validate the whole thing

that's a possibility. HIDDEN would be needed to avoid tab navigation 
inside hidden areas too.

a bigger issue is how to handle multiple FACES blocks for tab panels. 
maybe some kind of switching needs to be done.

Don't see the clue, it's only matter off hidding all the sub-panes 
except the current one ???

perhaps that's all that's needed. I'm not sure there isn't any rendering 
overhead.

keep it simple at first, we'll do some optimization if t's requested 
:)

an optimization would be to remove the hidden containers temporary 
but it can wait

henrik hidden widget is used to retrieve size sample for a character 
displayed on screen in draw using dynamically adapted font (according 
to the inputs setting of the user )

in area-tc for example of course this need depends on how the size 
x/Y of a char is obtainable

shadwolf, I'm not sure we'll keep using convoluted methods for obtaining 
font size information. we have the ability to make this nice and 
simple now.

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.