Bug 487616

I can confirm this happens with other window managers too (in my case Awesome WM on Arch Linux; a Google search also gives results for a thread on Manjaro forum where they've the same problem on i3).

*** This bug has been marked as a duplicate of bug 488853 ***

This is still happening on 6.2.0 for me.

6.2.1 hasn't solved it either.

This seems to be a different issue than the purported duplicate anyway because when shutting down (or rebooting, etc) I can still see the wallpaper and invoke a terminal and everything. In the other bug the screen is black and the tty is completely unresponsive.

In my case the wallpaper and all panels are gone, the screen is black, but I can still open a terminal (using Meta + Enter, a key binding I have set up in SXHKD). The window manager remains working, but the Plasma desktop is gone.

I noticed that if I press the power button on my tower the "power" overlay or whatever you call it (the semi-transparent overlay with the "shutdown", "restart" and so on buttons) does come up and the computer gets shut down properly. It's only when when I explicitly click "shutdown", "log out" or "reboot" from the applications menu widget that the problem occurs.

In my system settings -> "power management" -> "When power button pressed" I have selected "show logout screen", so this behaviour seems to be wrong as well.

There's a "bug" in plasma-workspace/startkde/plasma-shutdown

Shutdown::ksmServerComplete

    OrgKdeKWinSessionInterface kwinInterface(QStringLiteral("org.kde.KWin"), QStringLiteral("/Session"), QDBusConnection::sessionBus());
    kwinInterface.setTimeout(INT32_MAX);
    auto reply = kwinInterface.closeWaylandWindows();
    auto watcher = new QDBusPendingCallWatcher(reply, this);
    connect(watcher, &QDBusPendingCallWatcher::finished, this, [this](QDBusPendingCallWatcher *watcher) {
        watcher->deleteLater();
        OrgKdeKSMServerInterfaceInterface ksmserverIface(QStringLiteral("org.kde.ksmserver"), QStringLiteral("/KSMServer"), QDBusConnection::sessionBus());
        auto reply = QDBusReply<bool>(*watcher);
        if (!reply.isValid()) {   // ******************************you will be going into this path and it will cancel the logout. 
            qCWarning(PLASMA_SESSION) << "KWin failed to complete logout";
            ksmserverIface.resetLogout();
            logoutCancelled(); 
            return;
        }
        if (reply.value()) {
            logoutComplete();
        } else {
            ksmserverIface.resetLogout();
            logoutCancelled();
        }
    });

----

If you test a MR I'll approve it. 
Officially we don't support 3rd party window managers.

> If you test a MR I'll approve it.

How would I go about doing that?

> Officially we don't support 3rd party window managers.

Why does the `KDEWM` environment variable exist any why are there instructions on the KDE website? https://userbase.kde.org/Tutorials/Using_Other_Window_Managers_with_Plasma

Adding the x11-only keyword

In favor of software quality, there should be no dependency of states or data comming from other programs, in this case, independenttly of only supporting one window manager. This does not mean not taking advantage of them.

What do you tink of testing if kwin is running before calling the closeWaylandWindows method?
I don't know the correct way to do it. It seems wrong to search fot the executable name, but this is what I know how to do. I can share the patch anyway if anyone wants. Also I am not a C/C++ programmer.
I did the change bellow with good results on "<src plasma-workspace>/startkde/plasma-shutdown/shutdown.cpp" inside "void Shutdown::ksmServerComplete()" (added lines start with "+" and preexisting ones, only with extra spaces, start with "="):

+    QProcess procKwinRunninTest; // Declare the proccess variable to test if kwin is running
+    procKwinRunninTest.start("pidof", QStringList() << "kwin_x11" << "kwin_wayland"); // Run the program to search for the pids
+    if (!procKwinRunninTest.waitForFinished(1000) || !procKwinRunninTest.readAllStandardOutput().trimmed().isEmpty()) {
+        // If test didn't finish, assumes running. If result not empty, kwin is running.
=        OrgKdeKWinSessionInterface kwinInterface(QStringLiteral("org.kde.KWin"), QStringLiteral("/Session"), QDBusConnection::sessionBus());
 ... // Existing stuff, now only executed when a kwin process is running
=        });
+    } else {
+        logoutComplete();
+    }
=}

What it adds to the code: If kwin is not  running, don't try to connect and communicate, just call logoutComplete, as the calls that could fail are not needed because there is no kwin.

It would be nice if someone know how to test it in a better way.

Now it seems that I have the same problem with ksplash that I didn't find how to solve. I would appreciate directions on it.

I AM SORRY!
I send a version that has an error on comment #10.

This line:
+    procKwinRunninTest.start("pidof", QStringList() << "kwin_x11" << "kwin_wayland"); // Run the program to search for the pids

should be written this way:
+    procKwinRunninTest.start(QStringLiteral("pidof"), QStringList() << QStringLiteral("kwin_x11") << QStringLiteral("kwin_wayland")); // Run the program to search for the pids

(In reply to Fernando from comment #10)
> In favor of software quality, there should be no dependency of states or
> data comming from other programs, in this case, independenttly of only
> supporting one window manager. This does not mean not taking advantage of
> them.
> 
> What do you tink of testing if kwin is running before calling the
> closeWaylandWindows method?
> I don't know the correct way to do it. It seems wrong to search fot the
> executable name, but this is what I know how to do. I can share the patch
> anyway if anyone wants. Also I am not a C/C++ programmer.

The bug tracker is mainly intended for communication about the details of the bug. A better place to ask for help with a potential patch, or making development suggestions, would be to either
- Submit a patch via a merge request
or
- Communicate with the KDE developers on Matrix. The KDE New Contributors room would be a good place to ask questions.

See: https://community.kde.org/Get_Involved/development#Communicate_with_the_dev_team