[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