World: r3wp

What's wrong with your styles

they are a big jumble of experiments. not a good place to start from.

also there will be additions to DRAW which eventually will make style 
DRAW blocks easier to make, than in my experiments.

interesting - more info on draw additions, please? :-)

btw - what I liked about Gab's VID was gob dialect to build multigob 
composited styles ... but maybe Carl's VID does not need that ...

Just simple things to shorten draw blocks. I hope we'll get general 
hinting.

Gobs ... and goblets? ;)

Wasn't there any such game? Gobblets of fire? :-)

Pekr, Carl's VID uses a stack of identically sized GOBs that each 
perform separate tasks: Skin, text, debug. Each GOB stack makes one 
face. When designing a style, you never need to touch GOBs at all.

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.