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

james tittle tigital at mac.com
Wed Dec 1 17:08:23 CET 2004


On Dec 1, 2004, at 10:46 AM, IOhannes m zmoelnig wrote:

> 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 
> (?)

...yup...

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

...dimen sounds good to me...I'm just a bit new to outputting messages 
with lists/arguments instead of just numbers :-)

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

...ok, so this makes sense!  Now I just need to figure out, given a 
WindowRef in a callback, how do I get the dimensions?

> 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 ?

...I'm pretty sure I just globbed on an outlet:  actually, now I think 
I remember not putting in an output because of the following problems 
you highlight:

> 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 ?

...ok, now I understand what you were getting at:  again, I don't have 
much experience with writing objects that emit messages...but it seems 
the way to go!

jamie





More information about the GEM-dev mailing list