Hi J-S, Robert and others,
Looking at the even code in the GraphicsWindowWX it does look like the key press and key release should produce the same character key. The intent on the OSG side is that the keys should include by ascii characters that include the appropriate capitalization so it's the responsibility of the likes of GraphicsWindowWX to ensure this.
I'm the one responsible for the, somewhat weird, key handling in osgviewerWX. See this (http://www.mail-archive.com/[email protected]/msg00882.html) thread or the below excerpt:
"""I changed the EVT_KEY_DOWN handler to an EVT_CHAR handler, although that now makes the up and down handler assymetric. The new down-handler returns translated key codes, so when you press the S key (without anything else), it actually returns 's' and not 'S' as the EVT_KEY_DOWN did. This means that statistics can be called up in the viewer window, while the example previously only printed a "Stats output:" line to the console. I'm not truly happy that the up handler returns _untranslated_ key codes. But solving this completely would probably mean adding some table that translated from wxWidgets' untranslated key codes to OSG's internal ones. This might be interesting to add, as anyone using OSG + wxWidgets in any serious manner would also have to add this."""
I did not want to have to do any kind of key translation for such a simple example, so I left it as it was (using EVT_CHAR for key presses and EVT_KEY_UP for releases). Perhaps Thibault has some code lying around to do complete translation.
As far as the threading is concerned, I put in the SingleThreaded intialization as I wasn't sure if the GraphicsWindowWX class methods weren't going to be called from a different thread than the main wxWidgets thread. In wxWidgets, and most other GUI toolkits as well I believe, you can only make calls on GUI objects from the main thread. As GraphicsWindowWX::makeCurrentImplementation() and friends make calls on the OSGCanvas object (which is derived from wxGLCanvas) this might cross thread boundaries. But as I said I'm not sure if this was really going to be the case so I added the single-threading safeguard. I think I was experiences crashes with different threading models at some point, leading me to this "solution".
Regards, Paul _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
