get an excess Tab key report when switching back to an OSG
application (usually FlightGear :-). Although KDE has consumed
the Tab, it's sometimes still in the XKeymapEvent's key_vector,
and followed by a Tab KeyRelease event.
Avoid this artifact by
- asking for a "fresh" keymap (via XQueryKeymap()), rather than
using the unreliable(?) XKeymapEvent's key_vector, and by
- flushing all key events on focus-in (to avoid the KeyRelease)
After Super-press, Tab-press, Super-release, Tab-release (note
the wrong release order!) I still get an extra Tab event. But
this is not surprising and not exactly wrong either. Also it's
hard to avoid, as we can't see what happened to the keyboard
before we regained focus.
Files changed:
src/osgViewer/GraphicsWindowX11.cpp
include/osgViewer/api/X11/GraphicsWindowX11"
key, but it didn't pick up the initial state. So, if NumLock was on for
the OS at startup (LED on), it was still off for OSG. And the first
keypress turned the LED off, and NumLock on for OSG. The attached fix
picks up the state on every FocusIn, just like it was done in the last
commits for CapsLock. The difference is, that the NumLock mask isn't
standardized (e.g. 0x10 for Linux, and 0x80 for AIX), so we have to do
a reverse lookup (::rescanModifierMapping()).
Note that I could not reproduce the problem on my system, but someone
else confirmed it twice on his, and the patch fixed it for him.
Changed files:
./include/osgViewer/api/X11/GraphicsWindowX11
./src/osgViewer/GraphicsWindowX11.cpp
"
It sets osgGA's keymask when restoring keys on FocusIn, according
to the state values of XKeyEvent and XCrossingEvent. (These are
the only source for X11's current capslock state that avoids
pulling in the XKB extension.)
"
remain in pressed state after revealing, even if they are no
longer pressed on the keyboard. This can have bad effects,
especially if the stuck keys are modifier keys. One has to
press and release the stuck keys again to reset the wrong state.
The fix keeps track of all key presses and releases. On FocusOut
and UnmapNotify it releases all keys that are in pressed state,
and on KeymapNotify (following a FocusIn), it sets the currently
pressed keys again. To avoid confusion in the OSG-using application
normal keys are always reported released /before/ and pressed
/after/ modifier keys.
As current key states are returned as char[32] keymap by
XQueryKeymap and XKeymapEvent, this format is also used to
recognize modifier keys and for maintaining the current
internal key state. Functions to set/clear/query bits in
such a keymap are added.
The patch was extensively tested with osgkeyboard and
FlightGear under KDE and fvwm2. It was not tested on a
Xinerama setup or with multiple windows, but as _eventDisplay
is used throughout, there should be no problems. The patch also
makes the following changes:
- removes old and obsolete handling of modifier keys in ::adaptKey().
This wasn't only unused, but also wrong (and for that reason commented
out in revision 7066). The modifier states are actually handled
in ./src/osgGA/EventQueue.cpp (EventQueue::keyPress/keyRelease).
- fixes some spelling"
Stephan: "attached you'll find some modifications to the GraphicsWindow-class and
their platform-dependant implementations.
The problem:
setWindowRectangle and setWindowDecoration do not update the
traits-object, so, if you call setWindowRectangle on a
not-realized-window it will open with another size when realized later.
getWindowRectangle reports possible wrong sizes if setWindowRectangle
called before.
My solution:
split the implementation in two parts:
GraphicsWindow::setWindowRectangle will update its traits-object and
call afterwards the virtual method setWindowRectangleImplementation
(which is implemented by the derived platformspecific classess). For
setWindowDecoration I am useing a similar mechanism.
I hope you'll find the submission useful, the Win32 and X11 changes are
not tested but should work."
Changes to this made by Robert are call of resized in setWindowRectangle
instead of setting of Traits, and use of a bool return type.
window.
The win32 implementation is still in its original shape since I have no win32
implementation available.
I have chosen the enum approach for the first cut. That is benefitial since
the user does not need to track creation of mouse cursors for different
windows and displays in presence of multiple viewer windows.
The default set of available mouse shapes is the same set that was available
with glut. That set served many OpenGL applications well, so the hope is that
this is enough.
Even though, that implementation is still extensible:
I have digged out the way SDL defines new mouse cursors and added a still
documented out function prototype in the GraphicsWindow that can be used to
extend the current implemtation for arbitrary mouse shapes. That is not
implemented yet.
I hope that somebody with a win32 test system can catch up that implementation
on win32."
