World: r3wp

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.

rebolek, most of the times you are not using both. and using layered 
gobs is going to be faster, probably.

Gabriele, you should check code of some of my demos if you think 
I'm not using both ;) But if layering is faster then OK

i expect layering to be faster, because if you change one layer, 
it is not always necessary to recompute the other layers.

but... you guys need to ask these questions to cyphre :)

henrik: current docs do not talk about anything that could be shared, 
except the effect/draw/text blocks themselves.

that is, there is no font subobject.

i assume font object is referenced from the text block, so if you 
reference the same from many text blocks you are sharing it.

gabriele, ok, bad example. I was thinking more like for a star field, 
you could use one gob, referenced many times.

they would all have the same offset and size then :)

ok, so you reference one image in many gobs?