Summary: | KWin does not respect the NET_WM_WINDOW_TYPE for sub-windows. | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Nils Fenner <nilsfenner> |
Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | butirsky, kde, nate |
Priority: | NOR | ||
Version: | 5.22.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Nils Fenner
2021-09-05 17:03:51 UTC
sub-window or child with a transient parent? The file manager Window has to be parented, because pcmanfm-qt runs as a single process. FYI: When pcmanfm-qt is used as a file manager, it just fires a dbus call and quits afterwards (explains why the process is short-lived). That means: When pcmanfm-qt receives the dbus call (I will send it for debugging) it creates a QMainWindow as child of the QApplication instance. Otherwise the LXQt session would create a mem-leak on quit (and likely also segfault). (LXQt can probably workaround that by using a smart-pointer instead of parenting the window.) Actually I was wrong with the assumption of the parented window. The pcmanfm-qt MainWindow is a QMainWindow and unparented! Presumingly KWin makes the false assumption here that an application can only have one top-level window (parent == nullptr)! This is independent of window attributes and definitely a KWin bug. LXQt cannot workaround that! Here's a test application that cleanly reproduces that KWin behaviour: https://gitlab.com/antis81/kwindesktopwindow Actually this is rather simple to solve by enhancing the transient strategy. Would you accept a "collaboration" by LXQt on that issue? FWIW, I cannot reproduce the issue on wayland with the demo running as an xwayland client. (In reply to Nils Fenner from comment #5) > Actually this is rather simple to solve by enhancing the transient strategy. > Would you accept a "collaboration" by LXQt on that issue? Sure, if it's a kwin bug, we would be happy to merge the fix. Thanks for the feedbaack Vlad! We will discuss it and propose a fix. Feel free to ping me in #kde-kwin on OFTC. I'm zzag. @Vlad From our IRC discussion: All comes down to `BaseClient::bolongsToSameApplication()` (X11 client does not query this!). By changing the code in https://invent.kde.org/plasma/kwin/-/blob/master/src/layers.cpp#L736 it should work: ```c++ bool X11Client::belongsToDesktop() const { const auto clients = group()->members(); return std::any_of(clients.constBegin(), clients.constEnd(), [this](const AbstractClient *client) { if (belongsToSameApplication(client, SameApplicationChecks())) { return client->isDesktop(); } return false; } ); } ``` Since my login doesn't work currently can you do that? @Vlad Setting the window modality in the demo application has no effect on both (desktop and/or normal) windows. And it makes sense! Had a look at that deprecated Qt::WA_GroupLeader flag. If you search for "groupLeader" in kwin gitlab you will find the code is disabled. Talking KWin X11Client here: In addition we have "lxqt-panel" (separate process). Noteworthy that it doesn't set "Qt::WA_X11NetWmWindowTypeDesktop" flag and instead "Qt::WA_X11NetWmWindowTypeDock". What we have: 1. pcmanfm -> the only place where the "desktop" flag is set (https://github.com/lxqt/pcmanfm-qt/blob/aa2dc974840521afcd65a2e160641c2eef99ca16/pcmanfm/desktopwindow.cpp#L89). 2. lxqt-panel -> set the "dock" flag (https://github.com/lxqt/lxqt-panel/blob/7c0478ef9c7fc8998f7a7e0c844a8921e038d04d/panel/lxqtpanel.cpp#L167) KWin filters all "clients" (regardless of the process!) and determines which "belong to the desktop". With wayland it seems to be handled well now by that "KeepAbove" + "belongsToSameApplication" magic. Actually checking on the "dock" flag when cycling in "X11Client::belongsToDesktop" should work in both Plasma and LXQt (KDE independent) shouldn't it? (Does the Plasma panel set the "dock" attribute? If not, has it another attribute suitable?). |