[Development] Exposing QScreen API to QML

[Samuel Rødal]

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

Ok, so your argument is that one central controlling element in the 
application will make the decision and set the QWindow::orientation() 
property based on QScreen::currentOrientation(), and the other elements 
will react to that?

Screen as an attached property becomes less useful at least for the 
purpose of getting orientation information then (well, still useful for 
the element that actually sets QWindow::orientation()). It's then 
probably mainly the DPI information that sub-elements might care about.

Alternatively, we introduce QWindow::setSupportedOrientations(), and 
since the Screen element in QML is always associated with a window, we 
could filter out unsupported orientations in the QScreen -> QML Screen 
element bridge layer.

However, for the root element to be able to do rotation animations to 
transition between different orientations, it might be a good thing that 
sub-elements do not get the orientation immediately from the Screen 
element. I can see rotation animation being done by the root element 
having multiple states (landscape, portrait, etc), and using a shader 
effect (source?) to take snapshots of the element in the first state and 
in the second state, and does a rotation and cross-fade between the two 
snapshots.

--
Samuel