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

[Hans-Christoph Steiner]

FYI: I just subscribed to this list and I am resending this email in  
case it didn't make it to the list the first time.

On Dec 2, 2004, at 4:40 AM, Johannes M Zmoelnig wrote:

> Hans-Christoph Steiner wrote:
>> coming from Gem too.  Maybe the way to do it would be to have a   
>> [gemhid] object that outputs the same format as [hid].
>
> (i do not know how to write "have you read all of the postings in this  
> thread?" without appearing to be offensive. i don't know whether you  
> are on gem-dev; so i ask the question without offense)

No offence taken.  I am not on gem-dev so I haven't read this thread,  
and I haven't really done much with Gem, so I am at a double  
disadvantage.

>
> i really think that the information provided by gem is per-window.
> as i understand hid it is rather "global", in a sense that you do not  
> know where the information comes from. (well, it comes from "the  
> mouse" of course)
> now the problem here is that we want multiple windows with distinct  
> grabbing of hid-events (if we want "global" events, i think one should  
> use [hid]).
> [gemmouse] (and friends) does not support this, as there is no way to  
> specify the window it should listen too.
> so most naturally (for me) it seems to take pdp's (and others')  
> approach to  add an outlet to the [gemwindow] object that gives you  
> this kind of "feedback" from this window.
> the output of this outlet should be standardized, and most probably  
> the "HID format" would be the best choice (as ben suggested), as it  
> seems to be easily extendible to new features of new hi-devices (e.g.  
> scroll-wheels,...)

Sorry if this seems annoying, but I need to understand the whole  
problem before giving good advice.  The idea behind the [hid] stuff is  
that you are getting sensor data from the devices, with as little  
filtering from the OS as possible.  Correct me if I am wrong, but the  
basic goal with Gem seems to be to get pointer position data and clicks  
within that gemwin, so that's a different thing.  That's getting  
information from the OS about the pointer interacting with the window.

For example, something like keyboard data is not at all related to the  
pointer, so it doesn't matter whether you getting the events globally  
(i.e. from [hid]) or locally (i.e. from [gemkeyboard]).  The only  
difference is whether the gemwin has focus or not.  But if you can get  
the focus state from the gemwin, then you could use [hid] to get  
keyboard events for that specific window.  I think this would be more  
flexible.  The same goes for any element of a HID that is not directly  
represented in the gemwin (axes other than X,Y, mouse wheels,  
throttles, tablet pen tilt, etc. etc.).

So it seems that Gem should only handle the window interaction data  
(pointer coords, button clicks in that window), and output when gemwin  
has focus (maybe it does this already?).  The rest can be handled with  
standard Pd objects (i.e. [hid], or whatever).  This idea is a bit raw  
since I am mired in writing my thesis paper, but I think this direction  
would ultimately be the right approach.  Less duplicated code, fewer  
different objects to learn, more flexible, etc.

>> What I haven't understood about the Gem HID objects (gemmouse,   
>> gemtablet, etc) is why they need to be distinct objects from the   
>> standard Pd HID objects.
>
> sorry i do not understand this.
> if you complain about Gem's HID objects being unnecessary, you should  
> have written your [hid] some
>  years earlier (before april 1998; i am not sure whether HID was such  
> a buzzword back then)...

I had zero intention of complaining, I was just under the impression  
that y'all wanted to keep the gem HID objects distinct, and I wanted to  
understand why.  That's it.  I have only used Gem a little, and I  
haven't looked at the code at all, so in order for me to be helpful  
here, I need to understand what all is going on.

.hc


> why we have several objects [gemmouse], [gemtablet], [gemkeyboard] i  
> cannot really tell you. but it seemed a bad idea to output  
> keyboard-information to [gemmouse]...
>
>
>> The only reason I can see is to have absolute  coordinates that match  
>> up the the gemwin.
>
> these coordinates are relative to the position of the gem-window (not  
> absolute with respect to the desktop-origin).

________________________________________________________________________ 
____

                     There is no way to peace, peace is the way.
										-A.J. Muste