[Development] Predefined platform dependent constants in QtQuick components

[Alan Alpert]

On Tue, Jan 29, 2013 at 9:16 AM, Oleg Shparber <trollixx at gmail.com> wrote:
> Hi all,
>
> During development of the QtQuick2 application for BlackBerry 10 I noticed
> that all lists scrolls very quite slow. Same thing with any move of
> Flickable's content. The reason is the high resolution of the device's
> display.
>
> The problem is that there are constants which predefine behaviour of
> Flickable, PathView. Here's a short list of some of such #defines and
> corresponding component properties:
>
> Flickable:
>
> QML_FLICK_OVERSHOOT
> QML_FLICK_DEFAULTMAXVELOCITY
> QML_FLICK_DEFAULTDECELERATION
> QML_FLICK_OVERSHOOTFRICTION
> QML_FLICK_MULTIFLICK_THRESHOLD
> QML_FLICK_MULTIFLICK_RATIO
> QML_FLICK_MULTIFLICK_MAXBOOST
>
> PathView:
>
> QML_FLICK_DEFAULTMAXVELOCITY

Like the other ones in PathView, these are just duplicates of the
flickable defines. They should be set to the same thing if overridden
by the platform (and maybe they could just be moved to a separate
header both elements include).

> The actual documentation states that these properties are platform dependent
> and that is not true now.

They are for one platform. Some of these are defined in
qtbase/mkspecs/linux-g++-maemo/qplatformdefs.h

> I think, that the right way is to move these parameters to the platform
> plugins, so some platforms would be able to provide predefined constants
> while others like BlackBerry, Android or iOS would calculate them depending
> on device and display runtime information.

I like the idea of runtime evaluation for platforms supporting more
than one device. Ideally it should be in a way that single device
platforms can still use #defines though, I expect that would be a lot
easier for embedded users.

A question about fitting into the platforms though, do Android or iOS
scroll controls fix speed in pixels or speed in metres (actual
distance)? If it's a fixed pixel speed in all the platform native UI
controls, we might want to leave it as platform defines just to fit in
better (not that I mind surpassing the platform default UI toolkit ;)
).

> I am unsure about the implementation and maybe there are other thoughts on
> this problem.
>
> So, I would be happy to hear any ideas and would like to volunteer for the
> implementation too.

Sounds great :) . https://codereview.qt-project.org/#change,46130 is a
good start, we'll probably want to extend the current implementation
to cover BB10 while we think of the ideal solution for a later
release.

--
Alan Alpert