| Summary: | [systemd] Other WM are not loaded, only kwin | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Podagric <kde.podagric> |
| Component: | general | Assignee: | David Edmundson <kde> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | adam_tazul, Hi-Angel, jonah.chen, nate, ngoonee.talk, plasma-bugs |
| Priority: | NOR | ||
| Version: | 5.22.2 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Podagric
2021-07-04 15:21:17 UTC
This is expected 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" Will these changes make the new WM default and always load instead of kwin? yes, they would be permanent changes. but only for your user 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 (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? *** Bug 455335 has been marked as a duplicate of this bug. *** *** Bug 455370 has been marked as a duplicate of this bug. *** *** Bug 455452 has been marked as a duplicate of this bug. *** *** Bug 455882 has been marked as a duplicate of this bug. *** @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. @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). > 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?
(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? >Can it be officially supported? No. >Any ideas? I meant .service https://wiki.archlinux.org/title/KDE#Replacing_KWin_service is up to date (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 🤷♂️ 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. (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? 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? (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. |