I just want to enquire about the current status of gesture recognition. Id like to be able to scroll around a viewport without the mouse click events being sent to whatever is contained. For example, scrolling around a TreeView component without selecting the items if a finger is dragged across a touch surface.
How would I go about implementing such a thing?
Thanks
It’s something I’m also pondering at the moment.
My current plan is for classes like Viewport and ListBox to use MouseListeners to catch these gestures happening, and then add a new mouseClickCancelled callback so that they can interrupt the normal mouse-drag operation and take over. I’ve not actually implemented any of this yet though!
How about a more generic kind of MouseMask that can be applied to any component. This could be given an array of Gesture descriptor objects. If the mouse event doesn’t correspond to any of these gestures, the event falls through as normal. If a gesture is recognised, a callback can be triggered. Just a thought.
Maybe. It’s all stuff that I’m currently thinking about.
Jules,
I spent about two days altering the juce code and have implemented basic gestures and please let me make a suggestion. Don’t assume what user will do with the gestures and confine it to a few classes. Create virtual functions at the Component level. From what you stated above, you are assuming that only ViewPorts need a swipe. Not always the case and please don’t make this assumption. I use swipe to close a sliding panels and to scroll ViewPorts, and probably more uses like spinning a wheel.
Simply do something like this.
virtual void Component::GestureSwipe(…)
virtual void Component::GesturePan(…)
virtual void Component::GestureTouch(…)
etc.
This way you are not restricting the user and they will not have to hack the juce code. If they don’t like the default behavior they can override the virtual function and do whatever. I implemented this way to be generic and cross platform. The default behavior (Component class) can be to map them to mouse events as you’re currently doing.
If you’ll hold off a bit, I’ll cleanup my Gesture code within a few weeks and give it to you. This will save you some time.
BTW, you can’t have windows message WM_TOUCH and WM_GESTURE. You have to enable one or the other.
That doesn’t sound anything like what I was planning!
I’m not going to bloat the Component base class with any more virtual methods - instead I was planning to create some independent classes, e.g. ScrollGestureRecogniser, SwipeGestureRecogniser, etc which can be attached to any component you like. It’d require a few tweaks to allow these things to steal the incoming mouse messages from any child components once they spot a gesture, but would allow a lot more freedom to customise the behaviour, without needing to complicate the existing component hierarchy.
Goddammit, Windows… That would explain why the gestures aren’t getting through then. Ah well, doesn’t matter once these recognisers are implemented.
It would be great if you keep an eye on the Leap Motion SDK while doing this job… I’m just working on a helper class notifying registered objects with filtered and pre-digested information, thread safe. I do that to simplify interaction between the Leap Motion and the GUI. Notification are deferred in the main thread -> not for high perf capture, but great to control components.
Of course I can share if anyone is interested (to be taken as is, work in progress)
The listener approach works as long as any component can interpret the gestures how they see fit. A couple of notes seeing how I already went through this, You can’t use FindComponentUnderMouse routines. The end of a swipe may cross over into another component. So you need to save the component at the beginning of the swipe and use it throughout. Also it would be nice if you implemented Begin and End Gesture messages just in case someone needed them. And there should be an acceleration factor added for swipe. I think there should be a way on implementing either Touch messages or Gesture messages. This is enabled when the window is created. Touch messages are more powerful but require word because they are just a collection of points with supporting information. Some users may need this.
Good luck because Windows almost got it but not quite.