[Interest] QtQuickControls Slider and multitouch
nunosantos at imaginando.pt
Wed Dec 17 17:02:34 CET 2014
First of all thanks for your reply.
As far as I understood, there are a couple of patches ready to integrate and I could probably integrate them myself on my current Qt. If that is correct, I really don’t want to change my default Qt behaviour because, otherwise I would need to ensure that I apply the very same patches every time I update Qt.
Changing from a MouseArea to Multitouch area implies to change the source so I can’t make it from the Qml side, right?
In your opinion. Should I stick to my custom made slider for the controls I need this behaviour in?
> On 17 Dec 2014, at 12:22, Rutledge Shawn <Shawn.Rutledge at theqtcompany.com> wrote:
> On 17 Dec 2014, at 12:35, Nuno Santos <nunosantos at imaginando.pt> wrote:
>> I have just stumble on the lack of multitouch support for the Slider element in Quick Controls.
>> I can’t interact with more than one slider at once using the Slider element.
>> I had my own version of Slider using a Multitouch area and it was working great. I have now switch to Slider from Quick Controls and found that this is not possible with it.
>> Since Qt is more than ever a cross platform platform for mobile (and desktop are each day becoming more and more multitouch aware), I think this kind of controls should have multi interaction support.
>> Does anyone knows a way of overriding Slider touch handling?
> The tentative plan is to have MouseArea handle touch events too; then it will work. (Multiple-finger touch events can be broken up and dispatched to multiple Items in the scene, whereas only one touchpoint can be used as a synthetic mouse, because Qt only supports one mouse.) However it’s been controversial, and hard to get working 100% correctly in every possible combination of items too; that’s why the patches are not integrated yet. I also believe that if we start to directly handle touch events in MouseArea, we will need to do the same in every item that currently handles mouse events, because otherwise the scenarios in which one item steals the grab from another will not work correctly. That means Flickable at least. So, the following patches are mostly ready for integration, except that I’m not 100% sure that no regressions will be introduced, and I’m pretty sure there are a few autotests that don’t pass yet:
> An alternative idea was to create a TouchArea which only handles the simple touch use cases, like tapping and dragging, with an API that is mostly compatible with MouseArea. But that did not get done yet either, and I think it would be nice to have existing MouseAreas inside existing components just start working with multitouch. The controversy comes from the fact that we usually try to avoid behavior change, because we cannot predict what bugs it would cause; for example in a set of tabs, where each has its own MouseArea, what happens if you press two tabs at once? I think that in most such cases, at least something deterministic would happen. But maybe there could be some unknown bad cases.
> So probably in every case where a MouseArea was already in use, you will have to modify the QML to enable multiple-touch interaction. In the current version of the patch, you would have to set multiPointTouchEnabled: true, because it is not enabled by default. Or if we had a TouchArea instead, then you’d have to replace MouseArea with TouchArea. So it’s not a transparent upgrade either way. The Controls Slider will need this change to be done, if nobody has an objection to _that_ behaviour change, that suddenly all sliders can be dragged in parallel.
More information about the Interest