qt5base-lts/tests/manual/qscreen
Marc Mutz 11d6932560 Mark all of Qt as free of Q_FOREACH, except where it isn't
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:

Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).

In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.

Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2023-08-19 05:19:42 +00:00
..
CMakeLists.txt Mark all of Qt as free of Q_FOREACH, except where it isn't 2023-08-19 05:19:42 +00:00
main.cpp Mark all of Qt as free of Q_FOREACH, except where it isn't 2023-08-19 05:19:42 +00:00
propertyfield.cpp Fix build errors in manual tests 2023-01-20 15:48:20 +02:00
propertyfield.h Fix build errors in manual tests 2023-01-20 15:48:20 +02:00
propertywatcher.cpp tests: port assorted trivial uses of Q_FOREACH to ranged for loops 2023-08-14 23:11:54 +03:00
propertywatcher.h Use SPDX license identifiers 2022-05-16 16:37:38 +02:00
qscreen.pro
README

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). 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.