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