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

[Hans-Christoph Steiner]

This whole thing is definitely colored by my view of treating input  
devices like sensors.  But I think this would lead to the most flexible  
system with the least duplicated code and effort:

- [gemmouse] is not representing the mouse, but only the mouse cursor  
info.  A mouse outputs relative info, not absolute coords.  The  
current [gemmouse] outputs absolute coords of the cursor, whether that  
cursor is controlled by mouse, tablet, joystick, keyboard, eye  
tracking, whatever.

- Gem should handle window focus and window position.  Everything else  
can be handled in the regular Pd space, including mouse cursor coords  
and clicks within the gem window.

So I think that Gem should only output focus and the root location of  
each window.  Then everything else, i.e. getting data from HIDs, would  
be handled in the Pd space.  Then we need to create a [cursor] (or a  
better name? [ospointer]? [systempointer]? [mousepointer]?) object  
which gets the mouse cursor coords from the OS.  I think that you could  
easily implement all of the existing [gemmouse] etc. functionality with  
such a design, and make it work with multiple windows.

.hc

On Dec 3, 2004, at 3:57 AM, IOhannes m zmoelnig wrote:

> 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
>
>
>
> _______________________________________________
> GEM-dev mailing list
> GEM-dev at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
>

________________________________________________________________________ 
____

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