World: r3wp

tl: w/data/faces/1/names/tl

It's nice that face names aren't global, but hiding them like this 
a pane, I never remember the correct path.

pane = pain

You aren't supposed to have to remember a path - there's supposed 
to be accessors.

Yes, but currently there isn't any, is it?  (I am aware of the fact 
that the GUI is barely alpha)

You're too generous. The GUI is pre-alpha, and wouldn't be considered 
alpha without the layout model changes Carl has said he has planned 
(but then had to take a break to work on lower-level stuff for a 
year).

perhaps at initialization ... grab all the set words in names and 
store them in a block in the top window

It might not be a good idea to access these faces outside of the 
GUI code. There might be synchonization or multitasking issues.

that's going to make separation of gui from code more difficult

I mean accessing data from the actions rather than from outside code. 
Using the accessors to set state.

One shouldn't need to access faces directly. In time, I think GET-FACE 
and SET-FACE will do this, but you might need to pass the window 
face first:

get-face window my-form


Carl already has used a /field refinement, but I'm not sure what 
it does.

Someone should write a software book called 'The Joy of Naming'. 


We're used to 'facets, and I don't have anything against it, but 
it's telling that description for it uses both 'attributes and 'properties. 
I don't expect it will change at this point. We all just need to 
help new users learn what it means. 


'Template doesn't sound bad. It's funny, in OOP you have the concept 
of inheritance from a parent, but I don't know of a common term used 
for the view from the other direction. 'Attributes is probably the 
most common, but you don't hear it discussed as the base classing 
passing them on.

Henrik: make-gob is "complete" in the sense that it has all the features 
that were necessary for VID. I'm not sure I'd call it "finished" 
though - for example I wanted to add hinting, and a number of things 
may need improvements. Also, maybe the code can be cleaned up.

Gabriele, OK.

http://rebol.net/wiki/R3_GUI_Specs

This is not the list Carl made.

My take on naming - I will probably learn anything we come-up with. 
My english is pretty weak, so I am not a good measure, but I never 
ever used word FACET. I might have old brain already, but I always 
forget what it means. And I can assure you, there will be many such 
users as me. So more general naming would not hurt. It is really 
laughable, like we use special word (FACET), and then in its docced 
description to explain its meaning we use words like attributes, 
properties. So - why use FACET at all then? 


Quite contrary though, I was able to remember FACED. It sounded for 
me like sticked to the face instance :-) Anyway - I think that we 
have much more important things for the GUI to work on. And good 
docs with some diagram might be worth a thousands words ...

Henrik - who made that list, and how old is that?

I made it, and it's about 15 minutes old.

Going to add some more...

Henrik - at the beginning of this group, I reposted some of your 
older general notes about overal planned architecture changes. I 
think that it might become part of your document ...

Posted some of that. Still a lot left to do. Feel free to comment 
in here.

Henrik... great list ... not sure that the problem with field tabbing 
is in it or not.  In R2 tabbing went to hidden fields which made 
them visible.

That is specifically not the case here. Hidden faces are supposed 
to be skipped for tab navigation.

I think some of the requirements are more easily described as state 
machines. That makes it possible to implement them directly.

Great - thanks for the clarity..  Does anything about multi-lingual 
support need to be stated here -  is that inherently obvious or covered 
elsewhere?

No statement on multi-lingual support yet. Are you referring to input 
or simply the text language used in the GUI?

Only the text language displayed in the GUI.   If there is no position 
on GUI text language or user input  then I suggest that a statement 
 of same  belongs in R3_GUI_Specs so that it continues to be addressed 
or specifically ignored ... but will not be a surprise to new readers.

ok, good

henrik - perhaps inside-face could be called within-face? We already 
have within? function in rebol ....

other than that, it seems to me, there is way too much of high level 
functions ... I wonder if we really need all of them :-)

btw - what is the difference between freezed and disabled face?

We really need all of them. Badly. I use all of them in the VID Extension 
Kit.

A frozen face does not respond to input, but is otherwise normally 
visible. A disabled face is visibly disabled. Frozen faces may not 
be necessary, but they are a first step toward creating a GUI layout 
editor.

I think styles need to go in a separate document, or it will be very 
long.

Some of the global functions could be limited to the scope of the 
gui module and not exported.

Don't know which ones yet, just saying.

It's good to see someone going over the gui docs - the existing ones 
got a bit scrambled when someone reorganized the wiki with no understanding 
of the gui model. Docs for Gabriele's and Carl's guis were mixed 
together and the result made no sense.

For now, I'm ignoring the docs and sticking with the source. As the 
GUI system develops, we'll write new docs.

Who is able to go over the GUI docs to fix the mess?

Seems that an R3 face does not store its parent face. In order to 
traverse faces freely, the parent face must be known. Ideas?

So, what fields are there that relate once face to another?

Inward there is FACES, which is the block of subfaces. Outward there 
is nothing. It should be easy to add, but maybe there is a reason, 
it's not there.

I don't want to use the path from the window root, as the face object 
may be the only reference you have.

so you can go down but not up ...

Seems an omission ...

ohh... it's not inside the face object. there's even a PARENT-FACE? 
function.

face/gob/parent/data

not inside = not inside the root of the face object.

ok, PARENT-FACE? returns an error on window face. I wonder if it 
should do that.

because there's no parent?