Hi Serge, Am 22.11.10 16:41, schrieb Serge Lages:
> I don't really understand it, you also have push, drag and release events > send ? The compatibility with classic manipulators is something important > for us, we don't want to have to make a special manipulator if we use a > multitouch device even if we don't use the multitouch capabilities. In addition of the TouchData-structure the helper-methods in EventQueue simulate for the first touch-point a mouse-PUSH/DRAG/RELEASE with button 1. So, if you are only using one finger, you'll get the same events as when using a one-button-mouse (without the MOVE-events and with a populated TouchData-object attached to the GUIEventAdapter) If you are using more than one finger you'll get something along these lines: 1st finger touches the display : GUIEventAdapter::PUSH id: 0 TouchPhase::TOUCH_BEGAN 1st finger drag : GUIEventAdapter::DRAG id: 0 TouchPhase::TOUCH_MOVED 2nd finger touches the display : GUIEventAdapter::PUSH id: 0 TouchPhase::TOUCH_MOVED id: 1 TouchPhase::TOUCH_BEGAN 1st + 2nd finger drag : GUIEventAdapter::DRAG id: 0 TouchPhase::TOUCH_MOVED id: 1 TouchPhase::TOUCH_MOVED 1st finger release : GUIEventAdapter::RELEASE id : 0 TouchPhase::TOUCH_ENDED id : 1 TouchPhase::TOUCH_MOVED 2nd finger drag : GUIEventAdapter::DRAG id: 0 TouchPhase::TOUCH_MOVED // this is ios-specific, touch-points are numbered sequentially 2nd finger release : GUIEventAdapter::RELEASE id : 0 TouchPhase::TOUCH_MOVED // this is ios-specific, touch-points are numbered sequentially ... > Don't you think that the multitouch handle should be done by a > special GUIEventHandler (something like GUIMultiTouchEventHandler) ? We > should just add the touch ID to the GUIEventAadpter class and move the > TouchData management in this class ? This is a good idea, but I was unsure how to differentiate the stream of touch-events into "groups". How do you know when all touch-events "arrived" at the event handler? Do you store all PUSH/DRAG&/RELEASE-events and process them on FRAME? Or do you use the event-time to group touch-events? And I got some headaches modelling the class-inheritance-diagrams for classes inherited from e.g. TrackballManipulator and GUIMultiTouchEventHandler ;-) Hopefully my approach is a bit clearer now, it's the same as implemented by iOS. cheers, Stephan > > Cheers, > > On Mon, Nov 22, 2010 at 4:20 PM, Stephan Maximilian Huber < > [email protected]> wrote: > >> Hi Serge, >> >> Am 22.11.10 14:36, schrieb Serge Lages: >> >>> It's good to see a multitouch support in osgGA, but I was wondering why >> do >>> you need an extra structure (TouchData and TouchPhase) ? Just adding a >> touch >>> ID to the event and using the classic events (PUSH, DRAG, RELEASE) can do >>> the job I think. >>> >>> We're currently working with several touch displays in our company, and >>> that's what we do, we just add a UserData to the event with the touch ID, >>> and all the multitouch handle is done in the application side, it allows >> us >>> to stay compatible with classic mouse events with the same code (we juste >>> set the touch ID to -1) but we never worked on Apple hardware, mostly >> with >>> TUIO enabled hardware or Windows 7 compatible hardware. >> >> This was my first idea, too -- adding an id to GUIEventAdapter and >> adding one GUIEventAdapter per touch-point to the queue. After >> discussing this topic on osg-users, I decided to implement the current >> approach, as it simplify implementing multi-touch on the >> manipulator/application-side, as you don't have to track all >> touch-points and their states by yourself, as all touch-points are >> bundled in one GUIEventAdapter. You can query the GUIEventAdapter for >> the number of touch-points, etc. >> >> I am still open for different approaches -- Robert, what do you think? >> >> cheers >> Stephan >> >> >> >> >> >> _______________________________________________ >> 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 _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
