qt5base-lts/tests/manual/qscreen
Volker Hilsheimer 44fb925f50 Phase 2 of removing QDesktopWidget
Remove QDestopWidget public header, simplify the implementation that
maintains a Qt::Desktop type QWidget for each QScreen, and turn
QWidget's initial target screen into a QScreen pointer.

QApplication::desktop() now takes an optional QScreen pointer, and
returns a QWidget pointer, so that applications and widgets can get
access to the root widget for a specific screen without having to
resort to private APIs.

QDesktopWidgetPrivate implementations to look up a screen for an index,
widget, or point are now all inline functions that thinly wrap
QGuiApplication::screens/screenAt calls. We should consider adding those
as convenience APIs to QScreen instead.

Note that QWidget::screen is assumed to return a valid pointer; there is
code that handles the case that it returns nullptr (but also code that
trusts that it never is nullptr), so this needs to be defined, verified
with tests, and asserted. We can then simplify the code further.

Change-Id: Ifc89be65a0dce265b6729feaf54121c35137cb94
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-06-08 20:29:49 +02:00
..
CMakeLists.txt Convert all of tests/manual 2019-11-14 09:03:26 +00:00
main.cpp Phase 2 of removing QDesktopWidget 2020-06-08 20:29:49 +02:00
propertyfield.cpp QScreen manual test: fix conversion of enum values to names 2016-08-25 14:06:51 +00:00
propertyfield.h Updated license headers 2016-01-21 18:55:18 +00:00
propertywatcher.cpp Replace Q_NULLPTR with nullptr where possible 2017-09-19 11:53:55 +00:00
propertywatcher.h Replace Q_NULLPTR with nullptr where possible 2017-09-19 11:53:55 +00:00
qscreen.pro Manual QScreen test: capture screen changes. 2015-05-07 13:04:41 +00:00
README Fix the qscreen manual test for separate X screens 2015-05-12 08:58:52 +00:00

To test whether QScreen properties are updated properly when the screen
actually changes, you will need to run some kind of control panel to make
changes, and this test program at the same time. E.g. on Linux, you can use
xrandr with various parameters on the command line, but there is also a nice
GUI called arandr which will probably work on any distro. Real-world users
would probably use the Gnome or KDE control panels, so that's also a good way
to test. On OSX you can make changes in System Preferences | Displays, and you
can also configure it to put a "monitors" icon on the menubar with a drop-down
menu for convenience. On Windows you can right-click on the desktop to get
display settings.

Note that on Linux, if you have one graphics card with two outputs, typically
the two monitors connected to the outputs are combined into a single virtual
"screen", but each screen has multiple outputs. In that case there will be a
unique QScreen for each output, and they will be virtual siblings. The virtual
geometry depends on how you arrange the monitors (second one is to the right,
or above the first one, for example). It should be about the same if you are
using two graphics cards but using Xinerama to combine them. This test app will
create two windows, and will center one each screen, by setting the geometry.

Alternatively you can configure xorg.conf to create separate screens for each
graphics card; then the mouse cursor can move between the screens, but
application windows cannot: each app needs to be started on the screen that
you want to run it on (by specifying e.g. DISPLAY=:0.1 for the second screen),
or the application has to set the desired screen via QWindow::setScreen() before
showing the window.

The physical size of the screen is considered to be a constant. This can create
discrepancies in DPI when orientation is changed, or when the screen is
actually a VNC server and you change the resolution. So maybe
QScreen::physicalSize should also have a notifier, but that doesn't physically
make sense except when the screen is virtual.

Another case is running two separate X servers on two graphics cards. In that
case they really do not know about each other, even at the xlib/xcb level, so
this test is irrelevant. You can run the test independently on each X server,
but you will just get one QScreen instance on each.