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

On Wayland with Plasma, QMapShack's sub-windows (widgets?) become normal windows, and cannot be returned to the sidebars of QMapShack:

https://github.com/Maproom/qmapshack/issues/691

It works fine on GNOME, and on Plasma (Xorg). Is this the bug report I should be following, or should I make a new one?