[Development] Exposing QScreen API to QML

[lars.knoll at nokia.com]

On 11/21/11 12:42 PM, "Samuel Rødal" <samuel.rodal at nokia.com> wrote:

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

Exactly. So the Screen{} simply is a way to get notified about how the
device is being held. Window.orientation can then be used to tell the
compositor about how things actually look.

Then the orientation handling is fully in the apps control. Qt Components
might want to offer some convenience on top of this, but that's sort of
unrelated.
>
>> 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.

Ok, let's limit it to one DPI value then.

Cheers,
Lars