World: r3wp

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".

Gabriele, was make-gob entirely finished? It can still be useful.

I was just reading about upcoming new Facebook facelift ... and following 
the discussion I found out, that one person suggests very cool Facebook 
client done in Silverlight. I needed to download SL beta 4. Then 
I tried that mighty app. Guy, I can tell you - we can do it in View 
anyday. Its not any faster, any better, and I would really like to 
see the ugly code behind the app. My long time suggestion to popularise 
View is to wrap known services - gmail, FB, etc. E.g. especially 
on my Winmobile, ther's a FB client done by MS, and you can't even 
read more than 1 reaction to your post. I imediatelly can imagine 
Winmobile client in R3 :-)


Here's the screenshot - http://xidys.com/pekr/facebook-silverlight.jpg