Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.
Qt-contributors-summit-2013-QtQuick TouchMouse: Difference between revisions
AutoSpider (talk | contribs) (Decode HTML entity names) |
m (Categorize) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | {{Cleanup | reason=Auto-imported from ExpressionEngine.}} | ||
[[Category:QtCS2013]] | |||
Qt Quick handles mouse and touch.<br /> The problem is that we have a few components handling both, some only handle one or the other. | Qt Quick handles mouse and touch.<br /> The problem is that we have a few components handling both, some only handle one or the other. | ||
This discussion is about which direction we want to take in the future and how to unify the | This discussion is about which direction we want to take in the future and how to unify the "pointer" input handling. | ||
* MouseArea and Flickable handle only mouse | * MouseArea and Flickable handle only mouse | ||
* MultiPointTouchArea handles touch but | * MultiPointTouchArea handles touch but "eats" mouse events | ||
MouseArea and Flickable work by using synthesized mouse events.<br /> This is problematic because several MouseAreas /Flickables next to each other | MouseArea and Flickable work by using synthesized mouse events.<br /> This is problematic because several MouseAreas /Flickables next to each other don't work (on touch devices). | ||
Synthetization of mouse events from touch seems to be fast enough generally, but is far far from perfect. | Synthetization of mouse events from touch seems to be fast enough generally, but is far far from perfect. | ||
| Line 32: | Line 32: | ||
* 1 Several MouseAreas when using touch (only one will get events) | * 1 Several MouseAreas when using touch (only one will get events) | ||
** Piano App: several MouseAreas you cannot press two keys at the same time | ** Piano App: several MouseAreas you cannot press two keys at the same time | ||
* 2 With setFiltersChildMouseEvents we only go | * 2 With setFiltersChildMouseEvents we only go "down" to parent elements, but never back | ||
** Photo App: Flickable with PinchArea put down one finger to move the image, second finger to zoom, remove one finger -> moving | ** Photo App: Flickable with PinchArea put down one finger to move the image, second finger to zoom, remove one finger -> moving doesn't work any more… | ||
While we did not reach a clear conclusion we came up with two paths to persue. | While we did not reach a clear conclusion we came up with two paths to persue. | ||
| Line 45: | Line 45: | ||
==Issue 2== | ==Issue 2== | ||
We might need to keep track of not just the last mouse grabber but make it a | We might need to keep track of not just the last mouse grabber but make it a "stack" to keep track of all grabbers. Then we can pop back to an area more on top. | ||
==Conclusion== | ==Conclusion== | ||
We might need a vector of | We might need a vector of "stacks" of event receivers. | ||
Latest revision as of 17:31, 6 January 2017
| This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean. |
Qt Quick handles mouse and touch.
The problem is that we have a few components handling both, some only handle one or the other.
This discussion is about which direction we want to take in the future and how to unify the "pointer" input handling.
- MouseArea and Flickable handle only mouse
- MultiPointTouchArea handles touch but "eats" mouse events
MouseArea and Flickable work by using synthesized mouse events.
This is problematic because several MouseAreas /Flickables next to each other don't work (on touch devices).
Synthetization of mouse events from touch seems to be fast enough generally, but is far far from perfect.
It seems like there are 2.5 approaches…
- Make everything handle both
- What about more pointer/touch specific properties (touch point radius, right mouse button/wheel)
- Make everything handle only one of them
- App developpers have to add two areas to work on touch and with mouse
- Have a simple area that handles mouse and touch events as compromise
What about handling both simultanously?
- Do we even want to support that?
- Are there problems?
- Multiple mice?
Session Notes
It became clear that we face two independent issues:
- 1 Several MouseAreas when using touch (only one will get events)
- Piano App: several MouseAreas you cannot press two keys at the same time
- 2 With setFiltersChildMouseEvents we only go "down" to parent elements, but never back
- Photo App: Flickable with PinchArea put down one finger to move the image, second finger to zoom, remove one finger -> moving doesn't work any more…
While we did not reach a clear conclusion we came up with two paths to persue.
Issue 1
Short term it will make sense to make MouseArea and Flickable touch aware and fix
the MultiPointTouchArea to not simply swallow mouse clicks.
Longer term we might want several mouse events synthesized since that also makes custom mouse handling elements work.
Issue 2
We might need to keep track of not just the last mouse grabber but make it a "stack" to keep track of all grabbers. Then we can pop back to an area more on top.
Conclusion
We might need a vector of "stacks" of event receivers.