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

[IOhannes m zmoelnig]

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?

both.
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)


mfg.a.sdr
IOhannes