Make scrolling speed resolution independent

[Andrea Cimitan]

Following https://bugreports.qt-project.org/browse/QTBUG-35608 the default speed of scrollable components (components inheriting from flickable basically) is not resolution independent. The result is that scrolling speed on our high dpi touch screens is slow.

We could workaround this in the SDK until the bug is fixed upstream (I bet it won't happen in time for our releases), by simply adding components named as Flickable, Listview, Gridview etc etc in the Ubuntu.Components, where each of them sets the speed to be resolution independent following our GU guidelines

[Andrea Cimitan (cimi)]

Default velocity in qt was 2500, probably targeted around 96PPI... we can find something more reasonable with GU

[Florian Boucault (fboucault)]

Fix it properly in qtubuntu instead

[Florian Boucault (fboucault)]

It looks like I was wrong: qtubuntu cannot set those as they (QML_FLICK_DEFAULTMAXVELOCITY, QML_FLICK_DEFAULTDECELERATION) are defined in qquickflickablebehavior_p.h that says: "Platform specific flickable mechanics are defined either here, or in mkspec files."

[Florian Boucault (fboucault)]

See if qmlRegisterExtendedType could be used on QQuickFlickable as it is done for QQuickImageBase so that no new class needs to be introduced.

[Andrea Cimitan (cimi)]

This might work for Flickable, but won't for listview and gridview...

[Florian Boucault (fboucault)]

And why not?
Actually you should only need to do it for Flickable and it should automatically work for both ListView and GridView that inherit from Flickable.

[Tim Peeters (tpeeters)]

I proposed a somewhat related component in this bug: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1349426

If we had the proposed component and it would be used in all Ubuntu apps instead of using Flickables directly, that would make it easy for us to fix the flicking speed. Obviously that is not the case now, but I link the bug here anyway so you can comment on the ideas there.

[Andrea Cimitan (cimi)]

It won't work for Listview and gridview because they are inheriting upstream qt libraries and not our ubuntu components

[Andrea Cimitan (cimi)]

Having FlickablePage or ListViewPage won't fix this bug either, since all apps and code using Flickable won't have the resolution fix

[Florian Boucault (fboucault)]

Cimi, you did not try qmlRegisterExtendedType and you don't know how it works so saying it won't work on ListView and GridView is a little premature.

[Florian Boucault (fboucault)]

The qmlRegisterExtendedType does not work because in order for the extension QObject to be instantiated, an additional property has to be defined and also accessed in the client code.
Another technique was therefore investigated: overriding QtQuick's ListView/GridView/Flickable by using the same names. See linked merge request.

[Jouni Helminen (jounihelminen)]

could we please look into getting this fixed? would be a big win for many places

[Zsombor Egri (zsombi)]

Florian, actually the qmlRegisterExtendedType works on Flickable, you don't need to provide any additional property. See Image extension you provided for scaling images in toolkit :)

The problem is, that even if you extend Flickable, it won't get to ListView or GridView. using the parameterless qmlRegisterExtendedType function nothing will work, and using the (uri, major, minot, qmlName) works only if qmlName is set to Flickable, doesn't work if set to QQuickFlickable. More, you can extend only types which are exported from QtQuick privates, i.e. we cannot extend QQuickListView or the intermediate QQuickItemView class, neither of those have export declspecs.

I'll dig in further, maybe I find a better approach for the problem. Otherwise we have to provide separate UbuntuXXXX types for all. We have UbuntuListView, so we'd need UbuntuFlickable and UbuntuGridView. Also UbuntuPathView would be needed.

[Timo Jyrinki (timo-jyrinki)]

Adding more target packages. Zsombor mentioned there are possibly relevant upstream changes brewing to qtbase and qtdeclarative, although they have not been accepted by upstream yet.

[Zsombor Egri (zsombi)]

Checking the current changes added to the upstream bug I have doubts that those actually fix the issue we have. The fix smells like it only configures the threshold the flick should start, but doesn't configure the velocity at all.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity8 - 8.00+14.10.20141013.2-0ubuntu1

---------------
unity8 (8.00+14.10.20141013.2-0ubuntu1) utopic; urgency=low

  [ Michael Terry ]
  * Don't show initial lockscreen during the edge demo. The user just
    set up their phone with a password, it's pointless to ask them
    again. (LP: #1358283)
  * Distinguish between incoming calls and other dialer-app opens. (LP:
    #1378218) (LP: #1378218)

  [ Andrea Cimitan ]
  * Fix flickable speed to be resolution independent, by subclassing
    components (LP: #1348557)

  [ Michał Sawicz ]
  * Fix the ShellWithPin test and some functionality.

  [ Albert Astals ]
  * Move Base.qml to DashCategoryBase
  * Fix first item positioning when m_clipItem->y() is not 0 (LP:
    #1251597)
  * Fix some small qml warnings

  [ Daniel d'Andrada ]
  * Add touch ownership logic on top of qt input handling
 -- Ubuntu daily release <email address hidden> Mon, 13 Oct 2014 15:43:03 +0000

[Alexander Sack (asac)]

general comment: please try to submit bugs for product team landing request with many incomplete tasks etc. in future.

[Michał Sawicz (saviq)]

We decided to pull this out of unity8 and wait for proper upstream fix.