[Development] Exposing QScreen API to QML

[lars.knoll at nokia.com]

On 11/21/11 10:49 AM, "ext Samuel Rødal" <samuel.rodal at nokia.com> wrote:

>On 11/21/2011 08:48 AM, ext Alan Alpert wrote:
>> The thread about Window{} has progressed, and I still prefer that
>>attached
>> property approach compared to a Screen property on Window. The attached
>> property allows you to access the properties of your current screen
>>from any
>> graphical object easily, without having to find the current Window. If
>>we
>> added screen to Window, we'd then need to add a window attached
>>property so
>> that elements which didn't create the window can still find the screen
>> attributes (think components). Since there's nothing else in the Window
>>API
>> that arbitrary objects would need, I don't like having the extra
>>"Window."
>
>Good points. The only argument I could see against would be a desire to
>have rotation animations be centrally controlled. However, DPI and such
>might be useful even for sub-components. Though they need to be careful
>to use the average DPI and not the horizontal and vertical DPIs if they
>want to be rotation-agnostic.

Isn't it the Window{} that announces the apps orientation? Screen only
exposes how the device is being held by the user.

With regards to DPI I wonder whether the separation between dpiX and dpiY
makes sense on a QML level at all. Shouldn't we simply expose the average
DPI only?
>
>Another issue that's raised by creating windows for multiple screens in
>a single declarative context is that we want animation timers to be
>driven by vertical refresh. With multiple screens there might be
>different vertical refresh rates, which seems to imply that we would
>need to have multiple animation groups, instead of just one global
>animation tick. Any thoughts on how feasible this would be?

Gunnar told me that this requires some more changes in the internals. IMO
we should aim at a solution that works on a single screen (or at least
sync'ed screens) first before going further.

Cheers,
Lars

>
>The situation where the QML uses a single NumberAnimation to drive a
>property animation that's then used to animate some elements on two
>separate screens is a bit tricky. Either we disallow it somehow,
>discourage it through documentation, or find some way to detect it and
>run the same animation at two different rates.