[Development] Exposing QScreen API to QML

[Samuel Rødal]

On 11/21/2011 11:50 AM, Knoll Lars (Nokia-MP-Qt/Oslo) wrote:
> 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.

But who makes that decision? I imagined the decision might be made in 
QML, since for fullscreen applications it's up to the application itself 
which orientations it supports. The QWindow::setOrientation() is mainly 
there for giving a hint back to the compositor about which orientation 
the application is rendering itself in.

> 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?

Yeah, that seems like a good choice, at least until we see some actual 
demands for separating the two.

--
Samuel