[Development] status and use cases for QScreen

[Samuel Rødal]

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?

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

> I see that it corresponds to QML DisplayInfo.  And there is also QML
> Screen just for even more redundancy (but with less info than QScreen
> has).  I wonder what is the problem with exposing the QScreen objects
> to QML?  Somebody chose not to for some reason.

API-wise I'm not sure how QScreen would have been exposed directly. As a 
read-only screen property in QQuickItem? That might have lead to a lot 
of storage overhead, or signalling overhead as each and every item would 
have to be notified in the case of moving to a different screen.

Some discussion about the current approach can be found in the mailing 
list archives: 
http://www.mail-archive.com/development@qt-project.org/msg00178.html

--
Samuel