With these patches (and earlier ones) https://codereview.qt-project.org/#/c/87885/ https://codereview.qt-project.org/#/c/107504/ https://codereview.qt-project.org/#/c/107433/
we’ve been trying to fix bugs which have always existed in Qt 5 regarding behavior on Linux/X11 when screens are detached and re-attached: applications sometimes would crash, or sometimes stay running but disappear, no longer showing windows even when one more more screens are connected again. One of the most annoying cases is when you are running Creator on your laptop, you connect an external monitor to relieve eye strain, and move Creator there; then later you need to pack up and go, so you simply disconnect the monitor. The behavior has been different from version to version, varied depending on window manager, and on which screen was considered the primary. The approach I took is to ensure that nothing in Qt will crash when there are no screens (so some checks needed to be added), and rendering will stop. There were already other fixes in the past which dealt with letting the window manager move the windows back to the screen which got connected, or for Qt to do it otherwise. So in 5.5 the behavior I’m trying to achieve is that while you cannot start a graphical application if there is no screen, if you already had one running and then all screens were disconnected, the application continues to run without rendering; and if you then connect one or more screens, the application will start rendering again. That’s the worst case to handle, and yet you can see that non-Qt applications usually handle it just fine. Of course when a screen is removed, but one or more remain, the application should also not crash or disappear, and should be able to render on whatever screen its windows are mapped to. It may be a surprise though, for some applications, that QGuiApplication::primaryScreen() can return null in the case where there is really no screen attached. It’s a rare use case, but it’s possible that some applications could crash if they are using that pointer at the wrong time, without checking. And there are also some platforms where a dummy screen will normally exist even if no actual monitors are connected. It’s just that it doesn’t seem to be necessary to have one on xcb, so we are trying to avoid needing to create one artificially. It seems right to have the code modeling the real world: if there is nothing on which you can view the graphical output of your application, then there should not be a QScreen instance. Does anyone have any objection? _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
