Hi Shawn, 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? Regards, Nuno > On 17 Dec 2014, at 12:22, Rutledge Shawn <shawn.rutle...@theqtcompany.com> > wrote: > > > On 17 Dec 2014, at 12:35, Nuno Santos <nunosan...@imaginando.pt> wrote: > >> Hi, >> >> 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: > > https://codereview.qt-project.org/#/c/63308/ > > https://codereview.qt-project.org/#/c/65801/ > > 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. > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
