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