World: r3wp

EH?  Even in the on-make actor?

I don't understand the issue, so maybe you are right. What make-bogs 
did, was something different, no? It was about keeping multi-gobs 
togethere, setting their coordinate dependencies and z-order. But 
you hopefully know, what you are talking about, as I am not ....

Why do we need faces/facets at all? Seems:

	Window -> faces -> Gobs

could be:

	Window -> Gobs -> Gobs


If you need more attributes than the standard gob! provides then 
just make the data attribute an object! and put them in there.

Ashley, GOBs are not directly linked to faces.

Is face = gob! ?

<sigh>

Even Ashley doesn't understand the jargon .. QED

Ashley: nope. One face can consist of 3 GOBs.

GOBs are a means for rendering faces at a very low level. Just consider 
it like R2/View, where you, instead of having a cosed up system, 
can tinker with the inner workings of the FACE object in relation 
to View.

Without much understanding, I propose traits insted of facets.

http://www.rebol.net/wiki/VID:_Face

I could live with traits :)

Ashley, sorry GOBs _are_ linked to faces.

OK, a meta-gob to recreate R2 functionality (given that a gob! can 
only do one thing)? I understand why layout was a "face factory" 
under V2, just thought we'd naturally move to a "gob! factory" approach 
with R3. I'm not being critical, just trying to understand why we 
still need the concept of faces under R3.

but you don't need to manage them

Ashley, yes, we just have a bit deeper abstraction layer in R3. Things 
like MAKE-GOB can still be useful for other things.

Is that VID document I referenced still up to date?

Or does it refer to Gabriele's VID ?

No, this is for VID3.4. It seems to be up to date.

last update Aug 2007 .. that was before Carl wrote VID+

Sorry, no. That is for VID3. It has concepts like FEEL and LOOK, 
which VID3.4 doesn't have.

exactly

I put a warning on the document ...

the more I look at it the more I think settings is a better word 
than options

attributes is also better than facets

Answering my own question above .. this is shorter

code-text-list: text-list [
        content: [

            text-list-box :list-data :area-color options [ text-style: 'code 
            ]
            scroller
        ]
]

looks like 'comment { } is not allowed inside a stylize block

Is that a bug?

Ashley, "just trying to understand why we still need the concept 
of faces under R3." - The role of faces in R3 are just what they 
were in R2, a collection of features and functions inside an object, 
but instead of the underlying View system being closed, they are 
now linked to a fixed set of GOBs, that we eventually can extend 
with all sorts of features. So:

R2:

Layout -> Face tree -> View

R3:

Layout -> Face tree -> GOBs -> View


Faces are what are generated by the layout. So the "face factory" 
is still needed and styles are the "molds" or prototypes. Within 
the face factory, the GOB factory exists. I would assume this separation 
makes HW acceleration or replacing GOBs with a different structure, 
much easier later. GOBs are redrawn using DRAW-FACE and that is handled 
inside the styles.


Styles use resources like fonts, colors, materials and standard draw 
blocks. This eventually helps skinning and abstracts these things 
away from the styles themselves.


The obscure FEEL object is replaced with a set of on-* actors that 
are run at specific times in specific sequences during runtime. They 
are more fine grained, so you can determine what you want to do, 
for example during various stages of face initialization.


The relationship between the layout dialect and faces is a bit different 
than under R2: you can't access the whole face in R3, only facets. 
For example the GOB itself, is not a facet and neither are internal 
states. So in order to change a deeper element of a style, you need 
to create a new style. This seems cumbersome, but is badly needed 
for large layouts, where we are semantically separating appearance 
from purpose. VID allowed this to be an organic mess. We may figure 
out a way to make creating derivative styles a bit easier.

Graham, STYLIZE is a dialect, so it would need to support comments.

I see Graham is already submitting GUI reports to Curecode. I think 
we need a separate project for that. There could be hundreds of issues 
and they shouldn't be mixed with Core bugs.

No, only one report ... not reports :)

well, you might be tempted to submit more. :-)

>> stylize [ bt: button [] comment { }]

** GUI ERROR: Invalid style syntax: comment

Is that a GUI or core error ?  :)

that's a dialect error. Try to source stylize.

to be curious, what do you need the comment for?

Do we really need a r3 curecode project?

r3 gui

comments are for failed experiments :)

yes, we really need it.

We should ask doc ....

But there is a graphics section under cc

Yes, it should not be there. There are many subsections: Styles, 
layout, View, Text, DRAW, etc. We may face hundreds of reports on 
styles alone.

You're optimistic!

Or a pessemist :)

Better to be prepared for a flood of reports. I suspect the GUI might 
be a bit popular.

:-) So when the work on GUI is supposed to be restarted? Do we wait 
for its inclusion into HostKit section?

Need to finish a project first and then we're beginning. Hopefully 
next week. With a place to report bugs, you can start a little earlier.

If you need more attributes than the standard gob! provides then 
just make the data attribute an object! and put them in there.
 Right, and that object is called a "face".