[Development] status and use cases for QScreen

Shawn Rutledge shawn.t.rutledge at gmail.com
Fri Oct 12 22:24:55 CEST 2012

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?

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.

>> and bug-prone to just ignore the non-primary display, because why
>> would an application care about a screen which is just a copy of the
>> primary one, and doesn't add anything to the virtual desktop?
> Because that mirroring can change to side-by-side at any time.

Then you will see a new QScreen getting created, and the
QGuiApplication::screenAdded signal will be emitted.  And then if you
go back to mirroring, the QScreen which is not the primary in the
mirror set will be destroyed.

> What if the non primary screen is not the same size? The non primary screen would have different properties, so it probably shouldn't be ignored.
> I guess it depends on what you mean by 'ignore'.

I think that might not be possible on OSX.  When I connect my laptop
to a lower-resolution projector and turn on mirroring, the screen
resolution of the laptop changes to match the projector.

>> But
>> today I realized that making it behave the same on Linux is harder,
>> because you can use xrandr to arrange screens so they are
>> side-by-side, partially overlapping, or fully overlapping.
> Sometimes when dealing with hardware level stuff, you cannot make the API act the same on every platform and you have to go with what the platform does, as that is what it's users expect.

[NSScreen screens] will list them all, and CGDisplayIsInMirrorSet will
tell you if it's a mirror.  So I guess I should probably create
QScreens for the mirrors too; then it will be consistent between Mac
and Linux.  But as a user of the Qt API, then you would need to pay
attention to the geometry in order to discover which ones are mirrors,
because there could be 2 (or more) mirrors, alongside another screen
which is not a mirror, but expands the virtual desktop.  Adding
analogous info about mirror sets to QScreen doesn't make sense for the
sake of X11, because it's possible for screens to partially overlap.
Well maybe there could be a list of overlapping screens, so if there
is even partial overlap, it goes in the list?  It would save users the
trouble of testing intersections of QRects themselves in order to
discover the mirrors.

Then we'd have to see if it works the same on Windows.

More information about the Development mailing list