World: r3wp

Even if an official GUI is released tomorrow it will not be all things 
to all people and some will develop other gui's (rebgui, maxim's 
glass etc) why not start now as opposed to later. It need not be 
considered a folk of the offical vid...just an alternative choice. 
the official when released will be adopted if it works well enough 
so you won't be stepping on carl's toes.

folk>fork

Guys, remember that Carl WANTS help?  that means accepting ideas. 
 especially from like-minded people.

AFAIK, Henrik is closest to the source as to how Carl wants VID to 
evolve.  So if you (Henrik) want to put time and effort while the 
next host gets released, I say GO!  


Its time this community stops asking "what does Carl want" all the 
time.  He wants REBOL to be used.  he wants his last 15 years of 
life to mean something to more than himself.


Everything going into R3 is a direct response to what WE have been 
asking for the last decade.  He wants R3 to be what WE need, within 
a few guidelines we all agree to in the first place.


He wants REBOL to grow, and like a child that has grown... Some parts 
of REBOL will grow without him, others will grow with his counsel.

We aren't followers of a sect, waiting for praise from the prophet.


The more we take up projects and move them forwards without his daily 
intervention, the more the overall will be coordinated... 
right now, Carl is still too close to the code IMHO.  


which is why we don't have feedback on some of the projects we start 
work on (like schemes, for example).

The fact that brian has completely taken over parts of the development 
of R3, should be a clue, that there are other areas where this is 
possible.


This is all just my two cents, but in the last year that I have been 
chatting with Carl and some of the people which have "taken responsibility" 
for some stuff in R3, the more Its obvious to me that Carl just wants 
the community to do more... to take up more responsibility.

You got it right.

BTW, the GUI project will be coming back to life soon... and I'll 
only be one of several people working on it.

' :-/   
<sheesh> didn't know you where on line hehehe.

I'm really glad you're posting it. You need a blog.

I really like this line: "he wants his last 15 years of life to mean 
something to more than himself"

I think of that every day.

:-)

you should look at the REBOL3 /library group... quickly... give a 
bit of feedback on a proposed API I will start work on shortly.

Begun detailing the implementations here:

http://rebol.net/wiki/R3_GUI_Implementation

why is it that we can't use reflection functions on GOBs?

Carl why 15  and not 30 ?

Henrik, Some thoughts about the default STATES in faces.



DISABLED --> (the face is removed from its container or not constructed)

INACTIVE  --> (not reacting  to any events or actor, but still here 
and showed)

READONLY --> (reacting to some events (TAB, CTRL+C ...) but not modifiable)

HIDDEN --> (not showed but still in its container and can react (keep 
its place (spaced) on the screen))

hmm, yes, those are possible

notice that we should be able to combinate some of them together.
INACTIVE+READONLY
INACTIVE+HIDDEN

forget INACTIVE+READONLY

READONLY could be for information faces, which aren't INACTIVE.

can you give an example of HIDDEN?

yes or for labels

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.