[GEM-dev] Re: multiple_window: the questions begin!
IOhannes m zmoelnig
zmoelnig at iem.at
Wed Dec 1 16:46:37 CET 2004
james tittle wrote:
> On Dec 1, 2004, at 3:03 AM, IOhannes m zmoelnig wrote:
> ...also, as it is, the mouse coords are already converted to the "local"
> coords of the window, but they don't have to be...
so "local" means that 0/0 is in some (probably the upper/left) corner (?)
> ...ok, an outlet would be sensible: maybe we should output window
> relative AND global coords?
well, i am not sure whether global coordinates are really that
important, it would be more important to get the window-position (aka
"offset") when the window is moved.
as for now, all implementations of [gemmouse] (or rather, the underlying
callback-code) output the local coordinates.
>> 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?
yes, that's what i meant.
>> 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?
here i was referring to the output of the window, but of course we
setting the window-size with "dimen x y" should still be possible.
i just took the same name because it was the first that came to my mind.
i guess "dimen" (as output) is the choice to stay somewhat consistent
("size" never really made it for whatever reasons), but i see that it is
somewhat confusing when talking about ideas.
> ...I thought we could already normalize with gemmouse? It can take a
> scale value for x & y, at
yes, that is what i was talking about.
and i think that that is the reason why there are those additional
arguments. not sure without looking at the code; but i guess until now
the window-dimension (needed for normalization) was just read from the
GemMan variables. this will of course not work any more, if we have
multiple windows with different sizes which would be stored as
class-members within the GemWindow.
> least...and there is already mousewheel
> support: in the case of OSX, it's just another event message that is
> installed at window creation...
yes i know.
but how is it handled, is there a 6th outlet to [gemmouse] ? or is it
packed into the 4th outlet (middle button) somehow ?
the question is how to do data-retrieval (big words) in a way that is
easy to extend for future use.
[gemmouse] was just an example, because you ran into some problems when
you wanted to add the scroll-wheel without breaking things.
messages are probably simpler to extend than object-APIs.
and just to think about [gemtablet] (which i have never used because of
lack of tablets) which has about 10 outlets and what happens if your
brandnew tablets has 5 additional buttons ? add 5 other outlets ?
> ...so maybe we need to look at the specifics on individual platforms?
again i was not talking about the implementations but rather how to get
it right before too much work is done (avoiding frustration)
More information about the GEM-dev