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

[IOhannes m zmoelnig]

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