[Development] status and use cases for QScreen

[Lorn Potter]

On 15/10/2012, at 6:23 PM, Samuel Rødal <samuel.rodal at digia.com> wrote:

> On 10/12/2012 10:24 PM, Shawn Rutledge wrote:
>> On 12 October 2012 21:03, Lorn Potter <lorn.potter at gmail.com> wrote:
>>> On 13/10/2012, at 12:47 AM, Shawn Rutledge <shawn.t.rutledge at gmail.com> wrote:
>>> 
>>>> I got started working on QScreen, its properties, notifiers, and
>>>> implementation on all 3 platforms after I noticed that the
>>>> documentation was out of sync with the implementation in Qt5.
>>> 
>>> [on a side note]
>>> While getting reacquainted with qsystems, I noticed that if you added brightness, contrast, and maybe backlight state from qsystems to QScreen, we could get rid of the now mostly QScreen wrapper of QDisplayInfo.
>> 
>> OK, that would be interesting.  Sorry to say I didn't know about it.
>> But I wonder if it's reliable on all platforms?
> 
> Are these getters or setters? If getters only, what's the typical use 
> case for knowing these in the application?

getters only. QSystemInfo in mobility was 99% 'read-only' information.

> 
> If setters, are those settings something each application is typically 
> allowed to control?

I don't think a typical gui app would need to control the brightness or contrast of any screen, unless it was some more advanced video editing or playback software.

Something in the middleware layer might - brightness applet, or a daemon that controls brightness based upon ambient light sensor would.

The question should really be whether there is a use case for brightness/contrast getter without a setter, if that belongs in QScreen, and if it needs to be exposed to qml.



Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures