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)

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

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

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

mfg.asd.r IOhannes