World: r3wp

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

why would you need a color for an image?

why would you need a color for an effect?

well, of course, you are right ... but how do I do color of text? 
via rich-text dialect?

yes probably

gob/color is the background color, it would not be the text color 
anyway.

text color is done via rich text dialect afaik.

i guess, that if text is a string, there must be a font specification 
somewhere, with text color in it.

you say rich-text... so a page with a lot of rich text consists of 
one gob, not many?

one gob, exactly.

(one per paragraph maybe. we'll see.)

ok, I just thought that editing text might be heavier, if it didn't 
consist of several gobs.

as I understand it, you can have whole UI in one gob - if your UI 
will be done as one draw dialect block. probably not the fastest 
way anyway :)

correct.

so, can gobs be instanced? like many faces that share the same font 
object

what I don't like (but the design is still not finished so this may 
change) is that there is separate draw and effect block. I think 
R2 way (draw in effect) is much more flexible. Probably merging those 
two dialect would be best.