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

[IOhannes m zmoelnig]

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