World: r3wp

Your "template" and "model" are the most accurate, if not specific. 
The word "ideal" would require too much explanation.

they look like local variables to me ...

on-make: [

                face/facets/area-fill: span-colors get-facet face 'area-color [2.0 
                .2]
            ]

            on-resize: [ ; arg is the size
                face/gob/size: arg
                face/facets/area-size: arg - 2
                face/facets/diameter: (min arg/y arg/x) - 5 / 2
            ]

Ah, but they're not local variables. They're the prototype for local 
variables in another object.

And facets are the visible properties, not just any locals.

The faced object is the prototype - that's what I'm trying to name.

their usage is not shown in this example

ok, try 'defaults

Right, I didn't realize at first that you were talking about facets. 
I thought you were talking about faced. Defaults are what the facets 
object in the style object is. The faced objects are the prototype 
of the specifics (non-defaults).

faced objects are -> faced object is
And it might not be an object, I don't remember.

view/no-wait [ text-list []]
crashe if you try and use the mouse to close the window down

>> w: view [ tl: text-list []]
handler added

== make gob! [offset: 569x340 size: 142x120 alpha: 0 text: "REBOL: 
untitle

>> value? 'tl
== false

so how do you access the faces ?

that's another issue to solve.

you can access them freely from other faces in the layout.

Yes ... 
and some are 

set-face and others are set ...

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.