[Development] status and use cases for QScreen

[Shawn Rutledge]

On 16 October 2012 10:43, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
>
> On Oct 15, 2012, at 9:06 PM, Lorn Potter <lorn.potter at gmail.com> wrote:
>>
>> 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.
>
> As a platform developer I'm leaning towards "no": If it's in QtBase then every platform should implement it and I don't see enough use cases to justify the addition. It's fine and useful in a separate module.

It doesn't seem functional on a desktop PC anyway; I get -1 on Linux
and 0 on a Mac Pro for both values.  AFAIK there is no way to query an
external monitor for its brightness and contrast.  It works on an iMac
though.  It would be more useful if there were also setters, but I
agree it's not something we need enough to put in QtBase.

There is some duplication of functionality in DisplayInfo, including
platform-specific code to get the property values, which could be
reused from QScreen.  Maybe it could inherit QScreen and just add the
brightness and contrast.

Another thing I don't like is that to get these values from
DisplayInfo, you have to call an accessor, and you have to pass in a
screen number, even though QML in general is not screen-aware, and if
there is not even a way to enumerate the screens, how are you supposed
to find out what number to pass in there?  The values ought to be in
properties so you can bind to them.  But then there would need to be a
different DisplayInfo object for each screen.

I'm more concerned with why the QML Screen must have so little info
compared to the QScreen class, and why QML is not allowed to control
which screen a window is placed on, or even to enumerate all the
screens.  But as Samuel pointed out in last year's thread about this,
the main concern seems to be that if Qt Quick had access to all the
screens, they could be at different refresh rates, and animations
might not be kept in sync with refresh on both of them.  Still, even
if only one screen is allowed, there are several missing properties
which are more useful than brightness and contrast.  (Even the refresh
rate is missing.)  The other concern is whether adding properties
would have a performance or memory impact because of Screen being an
attached property on every Item.

Calling QWindow::setScreen is not enough to move a window to a
different screen, because it doesn't make sense for this function to
directly set the geometry.  When you start an application on X11, the
window manager is reponsible for positioning it, relative to the other
windows.  But there is apparently no way to ask the window manager to
move a window to a different screen and auto-position it there.  So
setScreen cannot move the window because the only way would be to set
the window's geometry to make it fall within the geometry of the other
screen, and we don't want to choose the coordinates automatically.  An
application can do it - call setScreen first and then setGeometry, but
I think that is not fully debugged yet.

This patch https://codereview.qt-project.org/#change,37221 adds the
extra info available from both DisplayInfo and Screen to the test/demo
app in qtsystems/examples/systeminfo/qml-deviceinfo, so that's a good
test for anyone who is curious.

In conclusion I think from the C++ perspective QScreen is in decent
shape (except for missing brightness and contrast, but maybe nobody
will miss it), but from the QML perspective neither DisplayInfo nor
Screen are very satisfying.  But having proper window support in QML
is more useful/important and maybe is a prerequisite anyway.  I'm
thinking Screen maybe should be a property of Window rather than an
attached property on Item.