Hi Thibault,
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 :)
To add to what Robert said, if you want to implement this suggestion I'd
be all for it. I think it's important that key handling be done in a
consistent manner so that GraphicsWindowWX can be used in the same way
as GraphicsWindowWin32 / GraphicsWindowX11.
On the subject of terminology, yes, the term "fundamental flaw" is a bit
harsh, but I agree with Thibault that this mixed handling of keycodes vs
characters seems a bit weird. IMHO, the OSG EventQueue should just be
concerned with the low-level keycodes, and the application (or the event
handler in this case) should combine that with the shift key state to
get whether 'a' or 'A' was pressed. It's a higher level concept that
doesn't belong in the low-level EventQueue, which should just process
the events themselves. (sure, there could be convenience methods
somewhere to translate the keys into characters, so that given the
keycode and state of modifiers you would get the translated character,
but it should not be done directly unless needed)
That's just my opinion, I don't have a submission to back it up so it's
just talk...
J-S
--
______________________________________________________
Jean-Sebastien Guay [EMAIL PROTECTED]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
