* 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