hi
Hans-Christoph Steiner wrote:
No offence taken.
fine!
Sorry if this seems annoying, but I need to understand the whole problem before giving good advice.
ok. a short summary: there are a couple of objects that get user-input "in the context of the gem-window", namely mouse, keyboard and tablet (i am not sure at all, whether [gemtablet] is limited to the gem-window somehow as i have never used a tablet. probably it is not. as Gem currently supports only one window, all the objects (at least mouse+keyboard) are related to this single window.
now we plan to support multiple windows in the future. user-interaction should be (in my opinion) per-window, especially if (as it is) the retrieved data (like mouse-position) is in relation to that window.
this shouldn't be a real problem with keyboard (and tablet, if (which is what i believe) it is not related to the "window" at all)
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.
basically true. i have added the [gemkeyname] a while ago, back then when there was only pd's [keyname] which only responded to key-strokes within pd's focus. this is "unfortunate", as we now have to provide a layer of compatibility which (in my opinion) must not depend on anything but Gem and pd (this is: no other externals must be involved)
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
that is correct.
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
i am planning to output a "focus" message just because of this.
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.
big words: "standard Pd objects (i.e. [hid]" ;-) anyhow, i agree that not each and every external that makes it's own windows should (have to) handle all the events that appear in that window (especially if they are not really window-related like joystick)
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
the only reason is backwards compatibility.. i have no personal liking of [gemkeyboard] at all (although might have been very useful to other people)
conclusions (not necessarily drawn from the babble above) in no order, and partly just my personal opinion:
+MUST: there must be a compatibility layer to the old [gemmouse] and friends (most likely built as abstractions)
+NEED: there *should* be no dependencies on other external libraries (we are going to have a hard time if people have to recompile their kernels because they don't have evdev-support which they need to get a [hid]-based [gemkey] to work again); otoh [hid] would be the choice as it is cross-platform (does it work on irix ?)
+NEED: window-related events (clicks in window, mouse-position, ...) should be handled on a per window basis, presumably as a message-output by the object that represents the window (e.g. [gemwindow]).
+[gemmouse] is window related and would thus be provided by Gem itself (and it is surely the mostly used of all gemhids)
+[gemkeyboard] (or whatever it's exact name is;-)) might still be "subject to change" (as the help-file says) as the output-format is not completely cross-platform, or was: gerard (i think) has submitted a patch that makes linux and windoze keynames be the same; no idea about osX though (does it work at all?); this gives us a lot freedom !
+[gemtablet] might entirely vanish and be substituted by a wrapper around hid. this seems contradictory, but the tablet-code does not work to well, is not cross-platform at all (it worked under NT but i have no idea about modern windozes with modern devices, i have no idea about linux (maybe works, but rather not), and i have no idea about osX (probably doesn't work)), as an object with umpteen ooutlets it is clumsy (sorry Mark). a compatibility abstraction should not be to hard to do.
and just an incomplete list of (proposed) messages that might/should be emitted by a [gemwindow] "mouse" (with x, y, buttons, wheels and stuff); "focus" "offset" (window position) "dimen" (window dimension) probably all information you get at the console when sending an "info"-message should be output as well. i am not sure whether "offset" and "dimen" should be sent automatically whenever they are changed by the user (by dragging the window and resizing it) or whether this should only be retrieved when the object gets polled.
ah long mail hope it makes sense mfg.muzt.ys IOhannes