On Tue, Jan 29, 2013 at 9:16 AM, Oleg Shparber <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
