Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QT5 not generate hide and show events in response to incoming Map Notify, Unmap Notify events.
We have a kiosk style application set with a custom window manager that among other things controls which application is visible via use of XMapWindow and XUnmapWindow calls.
We were running on RHEL 6.10 and QT4, but want to port to RHEL 8.3 and QT5.
When we ported to RHEL 8.3 and still QT4, things appears to work fine, but when we ported our first app to QT5 it stopped properly responding to the show and hide requests. As our apps depend on the show/hide events to properly handle all the display setup/cleanup, this is a problem.
What we seem to have determined is that the QT5 code, which receiving the Map Notify and Unmap Notify events, is showing/hiding the window, but not generating the QT show and hide events.
To test this, I wrote a small app that had a single window. It has debug prints whenever a show or hide event is called, and a native level event handle to report when Map and Unmap Notify's arrive.
On the Gnome desktop, using the desktop controls (minimize on the window frame and restore from the toolbar), show both the X event and the QT event. But directly sending the X Event (using the xdotool application) shows the X Event arriving at the application, but no show/hide events. Note that actual application on the desktop is as expected (so when using xdotool to generate an UnmapNotify, the window does disappear, just no QT hideEvent generated).
For comparison, I ran the equivalent QT4 tool, and it showed X and QT events for both desktop control and xdotool.
That's something you might want to check in the QPA xcb plugin.
I am not sure what you mean by that. Is it something to look up in the documentation, or a different forum group to ask the question on ?
Sorry, I meant the code of the Qt xcb platform plugin.
Well, I got the source (both QT4 and QT5), and am still not totally sure what is going on.
In QT4, basically QApplication processed the incoming events, and directly generated the QHideEvent during processing of the UnmapNotify.
In QT5, when processing the XCB Unmap Notify, the QPA layer basically invokes the WindowsSystemInterface::handleExposeEvent function with an empty region, which generates a private ExposeEvent which ends up being processed by QGuiApplication in processExposeEvent, which turns in into a QExposeEvent and then passes it to the normal application queue. It seems to eventually find it ways to QWidgetWindow::handleExposeEvent which is a private member attached to QWidget. It uses some Widget private data to determine if a HideEvent needs to be generated. But the logic for the event generation seem seperate from the logic to mark the window mapped or unmapped, so that could explain the issue we see (something in the logic).
But I know I did not get the entire processing chain, as I never managed to identify where the region in the QExposeEvent is used to determine which parts of the window are now visible (and sets a QWindow variable that indicates if the window is "exposed").
At this point, unless someone can point out something I missed, my best bet is to submit a bug report (I have generated a small sample app to show the issue), and do a work around. Most likely by using an alternate communications path from the Window Manager to the applications to make sure they change their widget visibility.
I have posted the issue to bug tracker with example program.