Hi Thibault, About the "fundamental flaw", it's not a difficult one to address - just add an extra entry for the low level key code in addition to higher level modified key codes. It can't be such a fundamental law though... as the OSG's GUIEventAdapter has been the way it is for many many years and none one has stepped forward to address this "flaw".
So a little sensible use of language here, it's just a missing feature that some users might find useful. Robert. On Fri, Sep 26, 2008 at 2:30 PM, Thibault Genessay <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
