e50416066c
The current way we do it of having the platform or touch plugin send both mouse and touch events is not ideal. There's no good way to write an application that works sanely both on a touch-only device and on a desktop except by restricting yourself to only handling mouse events. If you try to handle touch events you don't get any events at all on desktop, and if you try to handle both, you end up getting duplicate events on touch devices. Instead, we should get rid of the code in the plugins that automatically sends mouse events translated from touch events. This change enables that by making the behaviour fully configurable in QtGui. Two new application attributes are added to explicitly say whether unhandled touch events should be sent as synthesized mouse events and vice versa, and no duplicates are automatically sent as the current situation. Synthesized mouse events are enabled by default. We also get rid of the QTouchEvent::TouchPoint::Primary flag, which was only used to signal that the windowing system automatically generated mouse events for that touch point. Now we only generate mouse events from the first touch point in the list. Change-Id: I8e20f3480407ca8c31b42de0a4d2b319e1346b65 Reviewed-by: Laszlo Agocs <laszlo.p.agocs@nokia.com> Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@nokia.com> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@nokia.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com> Reviewed-by: Lars Knoll <lars.knoll@nokia.com> Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com> |
||
---|---|---|
.. | ||
qclipboard | ||
qdrag | ||
qevent | ||
qfileopenevent | ||
qguimetatype | ||
qguivariant | ||
qinputpanel | ||
qkeysequence | ||
qmouseevent | ||
qmouseevent_modal | ||
qpalette | ||
qscreen | ||
qshortcut | ||
qtouchevent | ||
qwindow | ||
kernel.pro |