* Robert Osfield -- Thursday 04 June 2009:
> I'm in two minds if I'd would classify this issue as a bug, and I'm in
> two minds about your suggested remedy. The code is it stands right
> now doesn't enforce a matching of presses and releases, it just the
> way it works. It's a bug if your assume that it does match.
Yes, and that's why applications can't do things for the duration of
a keypress. Consider the FightGear case again: pressing the SPACE
bar activates VoIP communication. If one releases the SPACE bar,
the microphone should be muted again. At the moment I can't rely
on that. There may never be a release event, because pressing the
Ctrl-key might modify 32 to 0. (Yes, we are hacking around this
unreliability, but that really only works for letters, as one can
assume that 'a', 'A', and 1 (Ctrl-a) are on the same physical key.
We can't make any assumptions for other keys.)
Making the physcial key number available in the event structure would
allow us to fix our problem in FlightGear, though I think the bug
is in OSG and should be fixed there.
> Making them match does require inserting artificial events that the
> the person at the keyboard has never instigated directly,
Yes, but no unreasonable events. Actually, these are the events that
anyone would expect. And it's not like OSG wouldn't add other artificial
keypress/release events already. Remember my last keyboard patches?
If the window loses focus (e.g. by desktop switching), then all keys
are artificially released. If it regains focus, they are all artificially
pressed again. And that wasn't a convenience thing -- it solved another
stuck-keys problem (because while the window didn't have focus, modifiers
could be changed outside, and the OSG app wouldn't notice).
> if you press
> an 'a' key, then press shift to 'A', then release the 'A' then that is
> the sequence events. What you haven't done is press 'a', release 'a',
> pressed 'A' then release 'A', which is what you are saying should
> happen be resented in events passed back from the OSG - this in itself
> could be considered a bug.
The problem starts where you drop information about what's *really*
going on (i.e. the physical key number), and replace it with keySym.
By dropping essential information, you take responsibility for the
sanity of what you pass. Keys that are undetectably, logically stuck
for the client are certainly not a feature. At least not one that
you'd want to mention in your ads. ;-) But I see your point ...
> I don't know what the solution should be yet, but I suspect it'll
> require some more information passed back via GUIEventAdapter, and
> make it easier to track unmodified key events. Whatever solution we
> go for it'll have to work identically across all platforms.
Adding the physical key number to the key events sounds like a good
idea, but it's a two-edged sword: OSG "client" code that relies on
that can easily make questionable assumptions about the keyboard
hardware and thus stop working on other input devices. (But then again,
assuming that '3' is next to '4' isn't any better, and we don't have
problems with that. :-)
But doing only that (without my patch) would require all clients
(that care about proper releases) to re-invent the fix. Adding the
fix to all platforms and adding a flag that says "this event is
artificial (was added by OSG), ignore it if you aren't into this
sort of stuff" might indeed be desirable.
m.
PS: in the patch I made a stupid untested last-minute change that
causes compiler warnings about signed/unsigned. Should have been:
for (unsigned int i = 0; i < sizeof(_lastKey) / sizeof(int); i++)
(But again, the patch was only a simplified version to show the
solution, and not meant to be applied.)
PPS: this was badly worded:
if (_lastKey[keycode] != -1) { // release key that isn't pressed?
Shouldn't
// happen, but just to be safe ...
the comment should have been:
// if the key was actually reported pressed
// before (which should really always be
the
// case, but better be safe)
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
