and another problem is:
example osgkeyboard is not work (keys not highlight) if user have 2 keyboard layout native and english and current user layout is native
I try to explain my changes
we need something that is identify key without modifier keys and layout -> this is UnmodifedKey
I think osg must have its own UnmodifiedKeys table. Code must be run same on different platforms. This can de guaranteed by UnmodifiedKeys table.
Mikhail Izmestev helped me. He implemented VirtualKey changes in GraphicsWindowX11"
osgGA. My approach is to bundle all touchpoints into one custom data
structure which is attached to an GUIEventAdapter.
The current approach simulates a moving mouse for the first touch-point,
so basic manipulators do work, sort of.
I created a MultiTouchTrackballManipulator-class, one touch-point does
rotate the view, two touch-points pan and zoom the view as known from
the iphone or other similar multi-touch-devices. A double-tap (similar
to a double-click) resets the manipulator to its home-position.
The multi-touch-trackball-implementation is not the best, see it as a
first starting point. (there's a demo-video at http://vimeo.com/15017377 )"
hyper keys defined already, but these modifiers were missing in
GUIEventAdapter::ModKeyMask, and the EventQueue ingored them as well.
The attached diff/archive adds the missing parts for Super/Hyper
modifier key support.
I'm aware that this might not be supported on all systems/keyboards
out of the box, but decided to submit it anyway because:
- developers are aware of differences between input devices
(Some mice have scroll wheels, others don't. Some have five or
more buttons, some have only one. Some keyboards don't have
numpads, some have AltGr, some don't etc.)
- even if someone relies on Hyper/Super in distributed software,
this is easy to fix and doesn't create lock-in conditions
- while the names Hyper/Super may only be common on X11, they are
just symbol names and not OS-specific
- even though some systems might not offer these additional modifiers
by default, it's likely that all of them have at least 8 modifier
levels internally, so it should only be a matter of OS configuration
to make them work
- having super/hyper available is useful to offer a user ways
to define local key definitions that are safe from collisions with
predefined "official" key assignments"
"StateSetManipulator.cpp (rev 1.12, l. 85): cyclePolygonMode() is called but
no aa.requestRedraw() afterwards. Is this intended?
EventQueue.cpp (rev 1.8): in keyRelease & keyPressed KEY_Alt_R was mapped to
MODKEY_LEFT_ALT"
"attached you'll find some modifications to Producer, osgGA and
osgProducer to enable Mac OS X support for
+ scrollwheels,
+ mightymouse-srollballs
+ new tracking-pads with scroll feature
+ tablet-support (pressure, proximity and pointertype) (Wacom only tested)
I think there was a bug in the windows-implementation of scroll-wheel
support (wrong order of ScrollingMotion-enum, casting problem) which is
fixed now.
The scrollwheel-code is a bit klunky across platforms, some devices on
OS X can report an absolute delta in pixel-coordinates not only the
direction, so for now there is scrollingMotion (which describes the
direction) and scrolldeltax and scrolldeltay. I decided to leave the
scrollingmotion-stuff to not break old code relying on this."
