Bug 439481 - [systemd] Other WM are not loaded, only kwin
Summary: [systemd] Other WM are not loaded, only kwin
Status: RESOLVED NOT A BUG
Alias: None
Product: plasmashell
Classification: Unclassified
Component: general (show other bugs)
Version: 5.22.2
Platform: Archlinux Packages Linux
: NOR normal
Target Milestone: 1.0
Assignee: David Edmundson
URL:
Keywords:
: 455335 455452 455882 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-07-04 15:21 UTC by Podagric
Modified: 2022-06-27 13:48 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Podagric 2021-07-04 15:21:17 UTC
SUMMARY:
I followed the installation instructions available at
https://userbase.kde.org/Tutorials/Using_Other_Window_Managers_with_Plasma
https://wiki.archlinux.org/title/KDE#KDE/Openbox_session

STEPS TO REPRODUCE
1. Enable systemdboot
2. Install another WM such as openbox
3. Restart and select plasma/openbox in sddm

OBSERVED RESULT
kwin will start even if the chosen section is plasma with openbox
by disabling systemdboot, openbox is loaded in place in kwin, with no problem

SOFTWARE/OS VERSIONS
Operating System: Arch Linux
KDE Plasma Version: 5.22.2
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2
Kernel Version: 5.12.14-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4790 CPU @ 3.60GHz
Memory: 9.6 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4600

ADDITIONAL INFORMATION
1. I tried disabling the kwin service, but it doesn't seem to change anything
2. archlinux adds a patch that creates the plasma/openbox section, but this can be easily reproduced on other distributions.
https://github.com/archlinux/svntogit-community/blob/packages/openbox/trunk/openbox-kde-paths.patch
Comment 1 David Edmundson 2021-07-04 15:46:18 UTC
This is expected
Comment 2 David Edmundson 2021-07-04 15:50:33 UTC
Urgh, bugzilla submitted whilst I was fixing the title.

It's not an officially supported config exposed in our UI.

Given on wayland we have a much closer bond between kwin and plasmashell I'm not sure how much it's worth investing time into fixing neatly with an alias and translating the existing config key.

It's resolvable from user config. 

Mask plasma-kwin_x11.target, create a new service for your new WM. Set it to be WantedBy=plasma-workspace.target and Before=plasma-workspace.target

Maybe we should just update that wiki with a second set of docs for "if you are using the systemd boot, do this intead"
Comment 3 Podagric 2021-07-04 17:13:20 UTC
Will these changes make the new WM default and always load instead of kwin?
Comment 4 David Edmundson 2021-07-04 18:27:16 UTC
yes, they would be permanent changes.
Comment 5 David Edmundson 2021-07-04 18:27:33 UTC
but only for your user
Comment 6 Podagric 2021-07-04 21:58:16 UTC
After setting the KDEWM variable I have the sections working correctly. I had Tried this before but for some reason it didn't work.
maybe sddm did not load correctly. but it's working for me now with emptty
Comment 7 Nate Graham 2021-08-02 14:43:56 UTC
(In reply to David Edmundson from comment #2)
> Urgh, bugzilla submitted whilst I was fixing the title.
> 
> It's not an officially supported config exposed in our UI.
> 
> Given on wayland we have a much closer bond between kwin and plasmashell I'm
> not sure how much it's worth investing time into fixing neatly with an alias
> and translating the existing config key.
> 
> It's resolvable from user config. 
> 
> Mask plasma-kwin_x11.target, create a new service for your new WM. Set it to
> be WantedBy=plasma-workspace.target and Before=plasma-workspace.target
> 
> Maybe we should just update that wiki with a second set of docs for "if you
> are using the systemd boot, do this instead"
I think so, yeah. Can you do that?
Comment 8 David Edmundson 2022-06-15 14:50:31 UTC
*** Bug 455335 has been marked as a duplicate of this bug. ***
Comment 9 Antonio Rojas 2022-06-16 06:38:30 UTC
*** Bug 455370 has been marked as a duplicate of this bug. ***
Comment 10 Antonio Rojas 2022-06-17 06:07:34 UTC
*** Bug 455452 has been marked as a duplicate of this bug. ***
Comment 11 Antonio Rojas 2022-06-24 12:40:59 UTC
*** Bug 455882 has been marked as a duplicate of this bug. ***
Comment 12 Konstantin Kharlamov 2022-06-24 12:52:38 UTC
@AntonioRojas was my report marked as a duplicate by mistake? This report is different: fist of all, it was created back in 2021, whereas my setup worked half a 2022 year, and only a recent Plasma release broke it. IOW I reported a regression, whereas this one is about something that wasn't working to start with.

The reporter was also enabling some "systemdboot" which I know nothing about and I presume I never did that.
Comment 13 ngoonee.talk 2022-06-24 13:01:23 UTC
@konstantin it is a duplicate, because your problem is due to systemdboot being enabled (default starting with 5.25 in Arch). If you want the old behaviour back disable it (Arch wiki has been updated for that).
Comment 14 Konstantin Kharlamov 2022-06-24 13:25:06 UTC
> It's not an officially supported config exposed in our UI.

Can it be officially supported? There's clearly a demand: this report already has 4 duplicates, and as the new Plasma version continues spreading to older distros, more users will be affected. Can we reopen the report?
Comment 15 Konstantin Kharlamov 2022-06-27 06:10:48 UTC
(In reply to David Edmundson from comment #2)
> It's resolvable from user config. 
> 
> Mask plasma-kwin_x11.target, create a new service for your new WM. Set it to
> be WantedBy=plasma-workspace.target and Before=plasma-workspace.target
> 
> Maybe we should just update that wiki with a second set of docs for "if you
> are using the systemd boot, do this intead"

There's no `plasma-kwin_x11.target`. There is `plasma-workspace.target` though. Any ideas?
Comment 16 David Edmundson 2022-06-27 08:58:21 UTC
>Can it be officially supported? 
No. 

>Any ideas?
I meant .service

https://wiki.archlinux.org/title/KDE#Replacing_KWin_service is up to date
Comment 17 Konstantin Kharlamov 2022-06-27 09:55:00 UTC
(In reply to David Edmundson from comment #16)
> >Can it be officially supported? 
> No.

Okay, why…? Sorry for asking, I just don't see any benefits you'd get by not fixing the env. variable parsing. My suggestion is just a matter of keeping  the report open till a motivated person appears (which might be me btw, that depends on how complicated that is to implement. At the very least I would try to look into that). The downside is obvious though: you'd turn away users, and let's be honest: tiling WMs are mostly used by developers. It is a precious resource to keep in a project 🤷‍♂️
Comment 18 David Edmundson 2022-06-27 10:53:39 UTC
Being able to easily swap out parts is one the core benefits of the systemd boot. 

Putting a layer within our units would be a hacky and messy design for everyone. I would block any such patches.
Comment 19 Konstantin Kharlamov 2022-06-27 12:03:29 UTC
(In reply to David Edmundson from comment #18)
> Being able to easily swap out parts is one the core benefits of the systemd
> boot. 

Sounds great!

> Putting a layer within our units would be a hacky and messy design for
> everyone. I would block any such patches.

Sounds contradictory. You just said how nice it is being able to easily swap out parts. We want to swap out kwin with another WM. Granted, I don't know at this point what exactly has to be done to support KDEWM in systemd. But do you really think it would be hacky? From my understanding, the biggest change that maybe has to be done is adding a script that detects KDEWM and if it's unset, runs kwin. It would be just one more service, what is messy with that?
Comment 20 David Edmundson 2022-06-27 12:20:29 UTC
Because you're creating a within a system that covers something we have already only worse as it's via a propriety undocumented env var.

Turning the question around, if you were to build from scratch, why would choosing a WM go via an env var?
Comment 21 Konstantin Kharlamov 2022-06-27 13:48:21 UTC
(In reply to David Edmundson from comment #20)
> Because you're creating a within a system that covers something we have
> already only worse as it's via a propriety undocumented env var.

I might be missing something: I don't currently see a way to properly cover replacing a WM while having Plasma systemd-boot enabled.  An approach that has been suggested (here and on duplicates) is basically editing systemd-service dependencies, so a custom WM is started instead of kwin_x11. There's a problem though: that would render you unable to start Plasma with kwin anymore.

IOW, with the KDEWM-way documented on wiki (and on github, which I assume was the original source) allows you to choose in SDDM between a "vanilla" Plasma session with kwin and the custom one with i3wm/whatever-wm. The "edit dependencies" approach requires you to hack around in a VTY if you wanted to switch between the kwin and i3wm sessions. And no more nice GUI option for you.

> Turning the question around, if you were to build from scratch, why would
> choosing a WM go via an env var?

I see! So, what you're up against is specifically having the env. variable. That means if we'd find a way to implement the functional with systemd but without the variable, that might be accepted.

Okay. With that said, I don't currently have a solution to that problem. I'll have to think, perhaps I'll figure something out.