Hi guys On Fri, Sep 26, 2008 at 2:24 PM, Jean-Sébastien Guay <[EMAIL PROTECTED]> wrote: > Hi Paul, > >> 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. > > Thanks for the explanation. We'll see what Thibault can come up with.
More about this keycode problem which goes far beyond the wxWidgets scope imho. 1) On the theoretical side, there exist two kinds of keyboard events: - key presses / key releases, corresponding to a physical key changing its state on the keyboard - character events, corresponding to the expected character being transmitted to the running program. This character might have been altered by the keyboard itself (with modifier keys), the OS or any intermediate layer OSes provide convenience methods for handling user input but even though we are not surprised to get a 's' character when we type the phyiscal key with an 's' sticker on it, this results from an interpretation and there is no one-to-one relationship between keys and characters. The OS itself manages this, according to the keyboard layout, locale and other settings that applications do not have access to - and should never try to tamper with. Most desktop applications only need to allow the user to enter some text. Those applications will never use the physical key events but simply use the character events. This way they can handle localization, keyboard preferences such as repeat rate, etc... transparently. Most OSG applications and games need a lower-level access to the keyboard. When you move left with the A key in a FPS, you don't expect 'A' or 'a' to be transmitted to the program. You just use a key that is convenient - you chose it because you were happy with the position of your hand on your keyboard and it could have been any other key. Furthermore you don't want the event to be repeated; you want to move left until the user releases the key. 2) There is a fundamental flaw in the way the OSG handles keyboard events. The OSG provides access to the keyboard events in a way that looks low-levelish with osgGA::EventQueue::keyPress() and keyRelease() but those functions actually process translated keycodes, aka characters. (I'm not blaming anybody here, just thinking out loud) I'm still wondering what could be the meaning of the event "The 'a' key has been released", and its difference with the event "The 'A' key has been released". Low-level key events should really look like "The VK_A key has been released". Now if VK_A is actually 'a' or 'A' (depending on the OS) it is only to help the programmer because it is convenient to identify a key with the character that is printed on it. The basic osgViewer::GraphicsWindowWin32 does not handle WM_CHAR, but only WM_KEYUP and WM_KEYDOWN. It further modifies the key code by using black magic translation rules and tables and sends the event to the osgGA::EventQueue. 3) Does the OSG need to remedy to this flaw ? I'd say no, at least not until osgWidget is feature complete and real GUIs start to be written. Until then, we can probably cope with the mixed keyboard model of osgGA. The case of a wxWidgets application (or QT, MFC) is even more simple since the user is probably going to type text in usual controls and interact in real-time with the OSG, and not going to type any text in the widget. 4) Provided that point 3) is acceptable, I'd finally suggest that we keep the consistency with the original osgViewer::GraphicsWindowWin32 and restore the EVT_KEY_DOWN and EVT_KEY_UP pairs, but doing a bit of processing as osgViewer::GraphicsWindowWin32::adaptKey() does. I am ready to implement this in the osgviewerWX sample since I've been bothering you guys with my blah blah :) Any thoughts ? Thibault _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
