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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development