* resthttp/osc: encapsulate RequestHandler-classes in their own namespaces to prevent class-name-lookup-errors in the debugger/code (had some weird crashes)
* QTKit: fixed a compile-bug for gcc and blocks
* osgPresentation: click_to_* will fire on RELEASE, only if the drawable received a PUSH beforehand
* p3d/osgPresentation: implemented "forward_mouse_event_to_device"-tag, which will forward mouse-events to all registered devices of a viewer, if an intersection occurs. The mouse-coordinates get reprojected
* present3d: all devices get registered with the viewer
* osgViewer: only devices which are capable of receiving events are queried for new events.
* GraphicWindowIOS: added a flag to GraphicWindowIOS::WindowData to set up a retained backing buffer (defaults to false) This will enable read-back of the render-buffer with glReadPixels even after the renderbuffer got presented
* curl: added an optimized check for file-existance, now only the headers are requested and checked, instead of reading the whole file and handle it with a ReaderWriter
* p3d: fixed a bug, where the existence of a local file may prevent the remote loading of a file with the same name.
"
10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
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."
