World: r3wp

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?

yes. it tries just to get the path, which doesn't exist.

one must ask for FACE/DATA/GOB/PARENT first

I'm also kind of expecting that the R3 GUI no longer uses objects 
for panes. That simplifies the code a little bit.

Just blocks ?

Either blocks in FACE/FACES or FACE/FACES doesn't exist. Some parts 
of a face is built dynamically as the layout is made, so if the part 
is not needed, it's not there. Yay for the ability to extend objects, 
I guess. :-)

The window face needs to know which face is the one tabbed to. This 
means it has to be extended with TAB-FACE. I wonder where it's best 
to do that...

Got basic face traversal working: LOCATE-FACE, NEXT-FACE, BACK-FACE, 
TRAVERSE-FACE, INSIDE-FACE?, FIND-RELATIVE-FACE, GET-TIP-FACE are 
now ported from the VID Extension Kit.

Requires no modification to VID3.4.

It can be tested here:

do http://rebol.hmkdesign.dk/files/r3/gui/traversal.r

I agree with Pekr that WITHIN-FACE? is a better name than INSIDE-FACE?, 
but you might disagree.

Next step is to store the tab-face in the window face, some key event 
handling and GOB display of a tab frame to get actual tab navigation. 
I imagine it could be nice to stow away different items in the window 
face, i.e. window related information. Suggestions?

BrianH, I'll change it.

Done.

I wish I had the time to review the GUI code right now, but I'm working 
on LOAD of compressed scripts/modules.

no worries. I need to spend the next 24 hours on another project. 
This was just to kickstart it.

Anything related to LOAD requires a lot of thought, since the code 
is so optimized. Tradeoff for efficiency, I guess.

There are a few changes in this, from the VID Extension Kit: All 
error generation is removed and replaced with NONEs. This was due 
to how VID is not pure enough a structure to work in. Consistency 
in the face tree for R3 GUI seems much better, but also because only 
a few styles exist and they all adhere to structure.