World: r3wp

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.

sorry, not NONEs, but FALSEs.

I've really been wanting to review the GUI code again. The R3 language 
is really quite different from when the GUI code was written.

yes, I'm sure there are plenty of tricks that can be applied now.

as a side note did anyone noticed carl that gob  has a pronounciation 
that means something for us ? Gobe in franche means  to swallow or 
in it's familiar sens to fall for  ...  detailed explanation on this 
link http://www.wordreference.com/fren/gober

there was a discussion in the beginning, because it means something 
gross (see urbandictionary.com), but he refused to change it.

lol

why I named my system GLOB a few years ago  ;-)

mean is slang here for mouth

GOB

Gob is an old english term for mouth - anachronistic, not slang. 
Shakespeare used it :)

Here's it's slang, and used as an insult

by those without Shakespearean training

http://dictionary.reference.com/browse/gob
and wikipedia back me up ...

It was used as an insulting way in old english as well. But a much 
greater proportion of the language was used to insult people back 
then - that's what people did with language.

so, we should call subfaces goblets ?

Yeah, we better get the event queue working, we have a lot of little 
mouths to feed :)

Henrik said he was starting working on the GUI this month .... is 
anything public happening?

BrianH, yes, now we just use variations of the F-word. It's a nice 
and elegant way to insult people. :-) Why can't other things be this 
simple.

Graham, not publicly yet.

F-word? Why :-)

hehe ... at least it's not the R-word!

I'm adding face tag handling to the specs document on the wiki, while 
also building the first prototype today for tag handling. Feel free 
to air suggestions.

If I knew what you were talking about ... maybe I could suggest!

ok, the basics are here:

http://rebol.net/wiki/R3_GUI_Specs#Style_and_Face_tag_principle

for rebol3 GUI what ever you put in it really it has to work the 
same way every where it exists .... the differencies between R2 windows 
and R2 linux are so big that advanced projects are a pain to make

main line should be SAME VID SCRIPT PRODUCE SAME RESULT ANYWHERE 
!!

and i think that comes really before anything else...

http://shadwolf.free.fr/area-tc23-linux.jpg
a teaser for what the rebol futur WILL  BE !!!

Shadwolf, those are low level things, so Cyphre is the one to bash, 
if it doesn't work everywhere. :-) With any luck the R3 GUI shouldn't 
have any need for adapting to various OSes and hardware.

i'm not bashing anyone ... i'm ust showing why rebol is considere 
as a toy and not as a professional solution

i'm less interested at pointing culpit than obtaining solutions. 
What ever is to blame that's not blaming people that we will get 
the things going on we need to show the potention and show that  
lot of differencies exists between OSes that supports lastest official 
rebol and then try to make the rebol 3 not repeating the same errors.

I'm starting to think that keeping a set of rules to parse for tags, 
may not be a great idea after all:

- Each rule is largely used only once.

- The rule list is quite short and there are not that many places 
to use rules.
- Building the parser is complex.

- The rule would have to be parsed on each invocation of a function 
which takes longer than simply searching for a tag. This would have 
to be done potentially hundreds or thousands of times on opening 
a single window and just consumes more memory.

- Setting and unsetting tags by using the rules as part of a state 
machine just leaves a new need for further processing the result 
where you use it, and perhaps slows it even more down, because you 
need a state machine engine to drive it.


The list of rules is good as a design guideline as I've used it for 
the VID Extension Kit, but no further than that. Tags are of course 
still needed.


I think I'll reduce today's prototype not to include rules, but simply 
manage tags directly.

hum you mean on the VID side no need to adapt the R3's script to 
any OSes. Yeah that's how it's promoted man ... REbol a unical VM 
of less  than 1Mo giving you the same thing avery where that's what 
the advertising said from the begining twelve years ago. And twelve 
years later we are still not there ...

Cyphre, Henrik, Ladislav and I are going to pic up the current VID34 
code and drive it forward. Our goal is to get it into a shape that 
it can be used to build apps.


We will try to sync with Carl about our steps to avoid that we fork 
away. Overall we want to solve the current stuck situation and move 
forward.


Our goal is to make VID34 useable for big apps. Focus is neither 
minimalistic nor "can be used by a child". This will be for the big 
boys. But still simpe to use and providing a bunch of features you 
need to make enterprise applications.

All this is done in the context of one of my companies: www.rm-asset.com 
that will sponsor the development.

good deal ... and why not a fork ? i mean VID3.4 can be used as module 
or side library

This is the software development company doing the commercial apps 
for other companies. Our goal is to create a professional framework 
we will use for all our developments.

I pretty like the idea of a more reactive VID made and maintained 
by the community   something with really open source that I could 
acces any time solve the bugs that's slows my  dev and share the 
patch i made. I'm better at finding solutions to existing problems 
than inventing new problems

@Shadwolf: If Carl doesn't agree with what we do or wants to position 
VID34 different than it will be a fork. Overall I still think we 
should avoid creating to much GUI forks and fragment our little community 
forces but instead pool forces to faster move forward.