On 12 Apr 2013, at 11:17 PM, Federico Brega wrote: > Thank you for your help. > I tried harder to get a single declarativeItem to handle all the > touchEvent and dispatches them to the appropriate side and it worked. > Unfortunately I barely have time for the application development > itself, so I'll wait for the beta 1 before trying Qt 5.1 . > Anyhow having this running on top of Qt Quick 1 will be useful for > testing on iOS, too.
We plan to have a solution for QtQuick 2 on iOS as well, but it's not there yet. >> But you can also use one MultiPointTouchArea per area of interest (per piano >> key), which sounds redundant since you only expect one touch on each; but >> the fact is MouseArea only handles mouse events, and since Qt doesn't >> support multiple mice, there also can't be two MouseAreas "pressed" at the >> same time. Whereas MPTA handles the touch events and ignores mouse events, >> so it's possible to touch multiple MPTA's at the same time. But I also >> found a bug, which I haven't fixed yet: if you press two MPTAs >> simultaneously, they get "stuck" and don't always go back to the released >> state (at least on Linux/X11). Hopefully I can get that fixed for 5.1. This turned out not be the sort of bug I thought: it's just that I also put a MouseArea on each key, because I wanted to handle both touch and mouse. But then the stacking/nesting order is problematic, because either MultiPointTouchArea or MouseArea can block the events for the other. (Maybe that blocking can be considered a bug.) MultiPointTouchArea by itself is working fine, and you should be able to use however many MPTAs you like, depending on whether it's more convenient to look at the touch points within one area, or to have multiple areas (like a touch version of MouseArea). _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
