[Development] Issues with QApplication::startDragDistance
Rutledge Shawn
Shawn.Rutledge at theqtcompany.com
Thu Nov 13 12:09:54 CET 2014
On 13 Nov 2014, at 11:11, Jeremias Bosch <jeremias.bosch at basyskom.com> wrote:
> Dear all,
> I was looking into deploying a simple QML App on a wide range of devices. The App consists basically of two QML Lists which are used for horizontal and vertical page navigation. The ranges of Display DPI differ a lot between those devices.
>
> Now there are two issues I ran into.
> • On High DPI cases the sensitivity of the lists is very high, basically touching the screen is already registered as a drag and pressing buttons is pretty hard. On Low DPI its fine. Of course you can tweak the startDragDistance with QApplication::startDragDistance, or the corresponding value in your Platform Style. However, this would mean that you need to adjust for each target device to get the expected behavior, which might not be possible and preferable - I think that the default value should respect the screen DPI.
> • I would like to have the vertical page navigation list to be less sensitive than the horizontal page navigation list and the horizontal page navigation list even less sensitive than all other "normal" content lists.
> I couldn't find a way to adjust the sensitivity on a case by case situation. All I found was a feature request https://bugreports.qt-project.org/browse/QTBUG-18792, but it was closed invalid back in 2011, without any comment.
> Maybe I overlook a feature and this is already possible?
> What do you think?
> • Wouldn't it make sense to make the default start drag distance respecting screen dpi?
> • What do you think about to add a property on the QML Flickable in order to customize startDragDistance for this one QML Flickable? Are there any concerns about having such a property?
Yeah we will get there eventually. e.g. there’s just a start here
https://codereview.qt-project.org/#/c/79480/
https://codereview.qt-project.org/#/c/91242/
But there are potentially a lot of these “feel” constants which should depend on the platform and on display density: the flick speed is slower than it should be, and the behavior doesn’t feel the same as in other apps on the platform. So they need to be adjusted in the platform plugin, IMO, or in some sort of platform-specific style or theme, rather than adding new properties to Flickable and other items, because you shouldn’t need to adjust them yourself. Correcting things that we should have already gotten right by default isn’t a good reason for cluttering up the public API, IMO. And we actually need more of such constants rather than assuming the threshold is the same for flicking as for dragging etc. And there are acceleration/deceleration, bounce behavior etc. which are actually hard to quantify with just a number or two.
More information about the Development
mailing list