World: r3wp

Bah - everything new is wierd.

anton, isn't this a simple matter of a search/replace in the global 
source tree of rebol 3? if there is a time to make a deal out of 
it, it should be now.

I agree with Anton on changing names. In fact, I have totally changed 
my mind about renaming REBOL or any parts of it. The reason is that 
it would make obsolete all the documentation, etc. It would be like 
throwing all that work away, and would cause terrible confusion. 
I was perhaps the most strongly in favor of a name change, but after 
thinking about it more deeply I've decided I was wrong. Also, I think 
that REBOL has been around long enough that a fairly long number 
of programmers have at least heard of it. And now that R3 is coming 
out, it is very likely that a lot of people will start to give it 
more attention. So this is not the time for change.

Louis - correct, and that is why I think it should be called face!, 
so the name would stay, it would just change its type from object 
to datatype :-)

but this is one word in R3... there are no docs yet on it. I would 
assume that the naming and design phase of R3 is not yet entirely 
complete. so if there is a time to rename things, this is the best 
time to do it.

in paint programms its called layer?

ah, layer, I like it. Most ppl working with photoshop or in general, 
will know it .... how is it called in web world? a box? (css)

I remember box in some old ZX Spectrum basic :-)

Well, if there are no doc yet, then a change may be in order. But 
for names already in docs I hold to what I said.

layer would imply that we have paint-functions like alpha. which 
we have :)

Anton, better now when all that needs fixed is RT's internal docs 
and source than hundreds of uses in the wild.  It really is an unfortunate 
name.  And there are some obvious replacements (over which there 
is no point in squabbling, we will not sway any decision).  Personally 
I think cell! or cel! would fit the bill.

face is not the same thing as gob.

vid will probably deal with faces, which in turn will refer to gobs 
for actual display.

a gob is just a graphic object, it does not contain a feel for example, 
and so on.

gabriele, how far is there from an image! to a gob! ?

(there are docs - not many, but not zero either. but i don't think 
that's the real problem with the change.) anyway... i'll tell Carl 
about this.

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