Hello,

Is this link relevant to this discussion topic?

http://vtk.org/gitweb?p=VTK.git;a=commit;h=e2c265ed92a33f161546aa9d4ef2500e8f9f8890

regards,
sebastian

On 30/01/2015 11:43 a.m., Martin Klemm wrote:
> Hi Christian,
>
> I also checked this page but then I read this comment in the documentation:
>
> https://qt-project.org/doc/qt-4.7/qml-gesturearea.html
>
> Cite: "Warning: GestureArea is an experimental element whose development
> has been discontinued. PinchArea is available in QtQuick 1.1 and handles
> two finger gesture input."
>
> I checked PinchArea in my QML App. It is useful but it is not helping
> you with the gesture recognition. You still have to write your own
> recognition code.
>
> At the moment I am stuck because of the way the DisplayInteractor works
> (see my other mail: Pointless DisplayInteractor in VTK 3D render window ).
>
> Best
>
> Martin
>
> On 29.01.2015 10:54, Weber, Christian(1) wrote:
>> Hi Martin,
>>
>> I like this approach. I'd voted also for the second option, which you chose, 
>>  that QmitkRenderWindow et al,  emit Gestures, this allows to use already 
>> existing GestureManagers for different frameworks. Also the 6 steps of event 
>> processing look really good!
>>
>>
>> I don't know much about QML so I googled a bit and found this:
>> http://blog.qt.digia.com/blog/2010/10/05/getting-in-touch-with-qt-quick-gestures-and-qml/
>> Can't we use this for basic gesture recognition ?
>>
>>
>> Best,
>> Christian
>>
>>
>> -----Original Message-----
>> From: Martin Klemm [mailto:martin.kl...@hs-offenburg.de]
>> Sent: Mittwoch, 28. Januar 2015 19:36
>> To: Clarkson, Matt
>> Cc: MITK
>> Subject: Re: [mitk-users] Touch interaction
>>
>> Hi Christian, Hi Matt, Hi all the others that are interested in this topic,
>>
>> after some days of researching ways to implement touch interaction I found a 
>> way. One thing that I recognized was that we do not want to bother with 
>> touch events, what we really want are detected gestures. In one way or 
>> another the touch events have to be converted into a gesture.
>> There are two possible places to do this:
>>
>> 1. directly in the DisplayInteractor
>> 2. in the QmitkRenderWindow respectively in the QmlMitkRenderWindowItem
>>
>> I decided to go with the second option. Qt already implements a 
>> GestureManager which has several GestureRecognizers to recognize the most 
>> common gestures. In the QmitkRenderWindow this manager can be accessed 
>> directly. So before converting the QT event into a mitk event the gesture 
>> manager will check the event for a possible gesture. If a gesture is 
>> detected a gesture event is emitted (after it is converted into a mitk 
>> gesture event). If no gesture is detected the incoming event is emitted. 
>> Subsequently the DisplayInteractor can react to these gesture events.
>>
>> But (!) this way just works for "standard" Qt applications and not for QML 
>> applications because they work slightly different. In the 
>> QmlMitkRenderWindowItem there is no gesture manager available, which is why 
>> I implemented my own one. This gesture manager is completely qt independent 
>> and could therefor work in all possible mitk applications (together with the 
>> DisplayInteractor).
>>
>> So the way I imagine it is the following:
>>
>> 0. User touches the screen
>> 1. QtTouchEvents are emitted
>> 2. In the QmitkRenderWindow, the QmlMitkRenderWindowItem or any other 
>> RenderWindowItem the incoming touch events have to be converted into a 
>> mitkTouchEvent 3. This touch event is passed to the gesture manager 4. The 
>> gesture manager tries to recognize a gesture 5. If a gesture is detected a 
>> mitkGestureEvent is passed to the render window, if not the touch event is 
>> handled 6. The Display Interactor handles the gesture event as defined in 
>> the state machine.
>>
>> So far I was not able to test it in the Workbench application because I am 
>> working with Qml. But it should not be a big difference. Moreover this is 
>> still a work in progress.
>>
>> What do you think about this approach?
>>
>> Best
>>
>> Martin
>>
>>
>> On 27.01.2015 22:09, Clarkson, Matt wrote:
>>> Hi Martin,
>>>
>>> How's it going?  If you had a design doc I could look at, then Im 
>>> interested. Maybe we can contribute?
>>>
>>> M
>>>
>>>
>>> On 27 Jan 2015, at 16:24, Weber, Christian(1) <ch.we...@dkfz-heidelberg.de> 
>>> wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> I  your approach  sounds good, we designed the Interaction having the 
>>>> application to a touch screen in mind, but so far haven't implemented 
>>>> anything in this area.
>>>> I also think that is good to integrate it directly into the
>>>> DisplayInteractor to handle such  events, just to be sure, you will need 
>>>> to map and create to some "mitkTouchInteraction" Events that derive from 
>>>> InteractionEvent  such that the Interaction Framework remains GUI 
>>>> Framework independent.
>>>>
>>>>
>>>> I'll be happy to assist if there are any more question, or look over any 
>>>> designs.
>>>>
>>>> Best
>>>> Christian
>>>>
>>>> -----Original Message-----
>>>> From: Martin Klemm [mailto:martin.kl...@hs-offenburg.de]
>>>> Sent: Donnerstag, 22. Januar 2015 18:01
>>>> To: mitk-users@lists.sourceforge.net
>>>> Subject: [mitk-users] Touch interaction
>>>>
>>>> Hi,
>>>>
>>>> I am currently trying to implement the interaction with a touch screen.
>>>> Did anyone work on this before?
>>>>
>>>> Our software is based on the QuickRender (QML) example and we use a touch 
>>>> screen instead of a mouse to interact with it. I am already able to 
>>>> receive the touch interactions from QML. These interactions I could send 
>>>> to the DisplayInteractor to process them. I would extend the 
>>>> DisplayInteractor in such way that additionally to the MouseEvents it 
>>>> could also process TouchEvents like Pinch, Zoom or Scroll.
>>>>
>>>> Is anyone interested in such an implementation, knows a better way or has 
>>>> experience to share?
>>>>
>>>> Best
>>>>
>>>> Martin
>>>>
>>>> ---------------------------------------------------------------------
>>>> --------- New Year. New Location. New Benefits. New Data Center in
>>>> Ashburn, VA.
>>>> GigeNET is offering a free month of service with a new server in Ashburn.
>>>> Choose from 2 high performing configs, both with 100TB of bandwidth.
>>>> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>>>> http://p.sf.net/sfu/gigenet
>>>> _______________________________________________
>>>> mitk-users mailing list
>>>> mitk-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mitk-users
>>>>
>>>> ---------------------------------------------------------------------
>>>> --------- Dive into the World of Parallel Programming. The Go
>>>> Parallel Website, sponsored by Intel and developed in partnership
>>>> with Slashdot Media, is your hub for all things parallel software
>>>> development, from weekly thought leadership blogs to news, videos,
>>>> case studies, tutorials and more. Take a look and join the
>>>> conversation now. http://goparallel.sourceforge.net/
>>>> _______________________________________________
>>>> mitk-users mailing list
>>>> mitk-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mitk-users


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
mitk-users mailing list
mitk-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mitk-users

Reply via email to