[GEM-dev] Re: multiple_window: the questions begin!

[james tittle]

On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote:
>
> [gemmouse] outputs (as we all know) the mouse-position in the 
> gem-window.
> now what happens if we have several gemwindows ?
> i think it there should be a mechanism to get the mouse-coordinates 
> attached to the window the mouse appears in. this is not really 
> possible with  [gemmouse].
> furthermore, [gemmouse] has several limitations (e.g.: no scroll-wheel 
> support; what about mice with 10 buttons ?)

...the way input works in osx is that whenever a window is created, you 
install some events that you are interested in (ie. mouse 
location)...then, whenever that event is seen during the event loop, 
the message is sent to the windows callback loop, and something can be 
done or not...one of the cool things here is that it can (and does atm) 
report back which window the event happened in...

...also, as it is, the mouse coords are already converted to the 
"local" coords of the window, but they don't have to be...

> now what should we do about it ?
> probably the simplest thing (as it is e.g. in pdp) would be to add an 
> outlet to the various gem-windows that would emit the state of the 
> mouse (or of any pointer).
> we could then build an abstraction (or do it in C) that sends this 
> data to [gemmouse] which would act as a global receiver.

...ok, an outlet would be sensible:  maybe we should output window 
relative AND global coords?

> as for outlets:
> personally i think by now(;-)) that it might be best to have just one 
> outlet and prefix the outgoing messages, like
> [mouse <x> <y> <bt1> <bt2> <bt3>(

...so this is a message that is output by the window?

> anyhow, we need several messages to query things like the dimension of 
> the window (or whatever): [dimen <x> <y>(

...again, should this be output by the window, or is it just received?

>> args:  x, y, w, & h...why were the w & h added?  I assume this is 
>> width and height of the window that is being tracked?
>
> yes. the idea was to get away from absolute coordinates.
> i mean, you had to rewrite (well: adjust) your patch everytime you 
> changed the window-dimensions (e.g. developping with a small window 
> and performing with a big one)
> so i though normalized coordinates would be a cool thing (e.g. 0/0 is 
> always upper left, 1/1 is lower/right)

...I thought we could already normalize with gemmouse?  It can take a 
scale value for x & y, at least...and there is already mousewheel 
support:  in the case of OSX, it's just another event message that is 
installed at window creation...

...so maybe we need to look at the specifics on individual platforms?

l8r,
jamie