World: r3wp

image! to gob! - they're completely different. a gob is a C structure 
that holds the necessary information to display something, like a 
piece of (rich) text, or a shape, or an image.

gobs are also arranged in a tree, similarly to how faces are.

face is the closest thing to a gob, but a gob is a much simpler object 
than a face. n gobs may be needed to obtain the functionality of 
a single R2 face.

I wonder why its not obvious to people that a gob is a single draw 
stroke.

so a button could consist of 6 gobs, one for each edge, one for the 
background and one for the text?

yes.

or you can have just one to draw the 4 edges with draw.

can you perform effects on a single gob?

also, if you use draw dialect only, you can still do almost everything 
with a single gob.

ok

effects - afaik you can either have text, draw, effects, image, or 
color for a gob. they are mutually exclusive.

image + text means two gobs, or use draw dialect (with i think same 
limitations as you have now)

but does the top level gob (of type effect) apply to all children?

i don't know, cyphre needs to answer this.

i think not - contained gobs are drawn above container gob

why those are mutually exclusive?

because the C struct only has one "slot" that can either contain 
an image, or a draw block, or a text block and so on.

how do you apply effect to image?

two gobs.

hmm, so tree of gobs is possible, right?

yep, see above.

I just wonder - some time ago, someone wanted the ability to "store" 
cenrtain rendering node,  could it be done with gobs, if they are 
separate?

you mean not recompute the AGG shapes at every show? i think Cyphre 
did it this way.

yes, it is what is PUSH for, no? But that concept imo collides here, 
because we have now separated draw, effect, image. But maybe it is 
not. I had some more difficult UI set-up in mind, and the ability 
to save certain rendition without the need to constantly regenerate 
it. But maybe that is done by compositing engine itself ....

how is event tight to gob?

push in the draw dialect? that saves the matrix on the stack, so 
i'm not sure i understand you 100% here.

events - events refer to the gob under the mouse afaik.

will there be event transparent gobs?

so the visible gob shape is tied to its event handling?

e.g. Tao had ability to have certain color (IIRC) defined, so you 
could have your events flow to underlying window ... but maybe that 
could be done other way ...

ask cyphre - but i think it is doable with mezz code. native code 
does not do much.

mezz code for such things? Slow :-)

we'll see :-)

hmm, now thinking about simple thing as red text - will it use two 
gobs? text and color are mutually exclusive ...

red text as the characters being red? that is handled by the rich 
text dialect.

if you mean background - then i think so, you have a bg gob and a 
text gob inside or over it.

but i don't know all the details (yet).

ah ... what is text then? or even better - what is following gob 
good for? gob: make gob! [color: red]

it is just color, but color of what?

background.

ie. a colored box

sounds scary ... as ZX spectrum, which could have only 1 color for 
particular bog pen, and one color as a background, where that gob 
was 8x8 pixels :-)

how can be such thing useful? You usually will need either - further 
draw help, or effect (gradient, well, which can be done by draw too 
;-) help .... for simple things, yes ....

but maybe it makes sense, dunno ...

this is done for speed and saving memory

ie it's faster and uses much less memory this way.

functionality-wise it's the same - just use n gobs instead of 1 face 
(could also be 1 gob with draw etc.)

I thought that usually you want simple thing as color be directly 
the part of each gob ... maybe it is more practical? But I would 
have to see how I do simple thing as view layout [text red "ahoy"]

is all text rendering part of rich-text now?

you do that as view layout [text red "ahoy"] :P