james tittle wrote:
yallo,
...ok, checked it out and started compiling and stuff...immediately ran
fine.
into a prob with the triggerMotionEvent(), which apparently takes four
admittedly triggerMotionEvent (or rather: all of the hid-things like mouse, keyboard and probably tabled) does not really work yet in multiple_windows. we should discuss this (that is why i put this on gem-dev too):
[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 ?)
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.
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>( this way we could always add another parameter to a certain message or just use a new message like [mouse_pos <x> <y>( [mouse_button 3 1( ok, the last 2 don't sound too convincing.
anyhow, we need several messages to query things like the dimension of the window (or whatever): [dimen <x> <y>(
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) to make it compatible with older versions of [gemmouse] (else this would break every single patch that uses [gemmouse]) i decided to make this behaviour dependent on parameters. so you could give the maximum output range as arguments [gemmouse 1 1] would normalize x & y between 0..1 [gemmouse 10 20] would scale x between 0..10 and y between 0..20 ideally [gemmouse 1] would scale x&y between 0..1 on square windows and between 0..1 and 0..x/y (or the other way around ? thats the big question; i think i t would be better to fix the y-axis and scale x appropriately as this would make "moving objects with the mouse" much easier) on rectangle windows.
mfg.as.dr IOhannes