[Development] Exposing QScreen API to QML

[Samuel Rødal]

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.

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?

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.

--
Samuel