World: r3wp

and, it's fast, don't worry :)

mezz code? slow :-)

no it isn't ;)

ah, you were faster, so actually it might be fast :-)

well, if mezz code can be rebcoded :-)

basically... the event gives you the window gob and the offset in 
it. then there's a native that can map an offset inside the window 
to the gob it belongs too. so the mezz code just uses that, then 
maps the gob to the feel, eg via gob/data (user data field)

so it's not much different from what R2 does, except that you have 
full control over it.

well, how is feel tied to gob? Is it automatically done, according 
to gob offset, and even offset? What if there is many gobs under 
the event offset? Hierarchy applies? Can we have event-transparent 
gobs?

if you had a game that was operated by keys only, for example, you 
would not need to do any of this, so it's even faster than R2

event > window + offset > gob at that offset > use gob/data to get 
to face object > face/feel/on-click etc.

since gob/data can be whatever... you can map any gob to any feel, 
gob b inside gob a may map to gob c which is elsewhere.

(map to same feel as gob c)

or you put an id in gob/data and then use that to do whatever you 
want

or you don't map the offset to the gob at all, but use a bitmap to 
map the offset to something else, like max does in elixir etc.

gob being elsewhere - I remember one cool thing about QNX, back in 
1998, when they were supposed to be new AmigaOS - their Photon environment 
allowed you to insert "face" (gob) across the network - two machines 
were linked via some nodes, so for the GUI it was transparent. Window 
received the event, and that event in fact was transfered to another 
PC's window ...  was cool :-)

since you can make event! in R3... you could get event on one PC 
and then send it over to another PC and handle it there. :)

yes, but rebservices will be slow :-)

it was a joke ;-)

:P

great ingo on the events Gabriele - that will make networked games 
much more viable

event > window + offset > gob at that offset > use gob/data to get 
to face object > face/feel/on-click etc.

 - that sentence might actually help me to better understand the concept. 
 So gob is not necessarily child of face. It is completly separate 
 concept - kind of gfx node. And that node points to higher concept 
 - your face, or whatever you want, so you can do anything ....

info..

exactly.

gobs are just... graphic objects :)

that seems to be nicely flexible ... most of the time, at least for 
static things, you maybe will not need higher level complex structures, 
so it will save resources ...

at present I am re-writing all controls in draw only mode so that 
when we eventually get access to OpenGL surfaces I have less pain 
:)

faces are higher level... they have a feel, other info needed for 
eg for vid, etc.

but you don't need to use "faces" at all, you can just use gobs in 
a game for eg. and handle events your own way... maybe gob/data maps 
to the player object :)

good to know

how that gob/data points to face/feel/on-click? is there a mezz code 
in gob/data?

hmm, it would be coold, if you could post any simple actual code 
as a spoiler - we can already learn from studying :-)

wait a month (less actually... it's 4 already)

:P

id rather wait a month and have to docs out :)

gob/data can be integer, object, block, i think also string/binary

the

moving fill and pen inside the shape block would also be nice to 
complex shapes

or just adding a fill-at command

fill-at - that's a problem with anti-alias

yes

paint programs have the same issue

normally you set a tolerance

or introduce a feather border

that gets a bit complicated :)

very :)

altho you can cheat with alpha for feather borders

but if we get rebcode eventually we can do that in the community

i suspect it would only be used in image greation programs anyway

A menu generator for AGG - work in progress ;-)   http://rebol.mustard.co.nz/menu-wip.png

size-text is my new friend - that and para/wrap?: off ;-)