On 16 October 2012 10:43, Sorvig Morten <[email protected]> wrote: > > On Oct 15, 2012, at 9:06 PM, Lorn Potter <[email protected]> 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
