KDE Plasma 5.21 Bringing Systemd Startup Support, Wayland Improvements

[intelfx]

Plasma now uses systemd for startup when it's present. This should lead to faster startup/load times and other improvements as a result. But it's not landing until Plasma 5.21.

Next step, throw away kded.

So if it will be started by systemd, then maybe we can use systemd to restart it in case of problems and systemd can put it in it's own slice / cgroup to have higher priority than other processes, so it's always faster and smoother than everything else.

Yeah. Apparently KDE is following in GNOME's steps. Very happy to see that.

[intelfx]

One possible fix is to use systemd's KillUserProcesses (I have set it to "no" because I don't want systemd killing my tmux session)

You don't have to. Run tmux in systemd --user and enable linger.

[gregzeng]

Desktop Environment comparisons ahead! KDE vs GNOME vs Cinnamon vs XFCE vs MATE vs LxQt vs the window manager, etc. Unusual is this press announcement, since it is not written by journalists; the context is not shown. Previously Wayland display servers & systemd process launching were considered independent sub-units in the operating system. GNOME & KDE are unusual in that they are both integrating these sub-units into the DE.
Hopefully further integration will be easy for the various package managers: Deb, RPM, AUR, Puppy, snap, Flatpak, appimage, etc.
Linux itself still stays very disorganized. The many waiting application writers are very upset by Linux. Which package manager? So Linux on the Desktop, on the handheld, continues to be a very lonely loser, far behind Windows, Apple and open-source Android.
Press coverage in our information industries is similar to transport journalism, where the comparisons are easily made. Journalists & testers become better at measuring & describing these products. Wikipedia editors like myself try to compare & document our findings from the endless reports & comparisons.
In this KDE report, no mention of the biggest failing: undo for the most flexible DE ever. Can we save our custom defaults, for ready application, or transfer to other environments, or other operating systems, like my use of Firefox or Chromium-based web browsers?
In terms of customizing, KDE as usual is the leader. The other "losers" are trying to emulate some of the KDE features. In terms of resource use, KDE is often measured as being "lighter" than XFCE. GNOME is heaviest and least flexible.
CIO & CEO staff remain appalled at the technical competence of the writing staff. In other industries (transport, audio-visual, education, military, retailing, finance) the industries are far more informed & competent, compared to the Information Technologies.
Probably the problem of very poor IT journalism is due to the very rapid rate of change. "Future Shock" affects this more than other industries. The true advances are in the Dark Web. All the big players need & use the Dark Web, for monitoring the protection of their own processes, as well as knowing the future prospects of their own products, compared to the wider environments.
The MBA type of workers are missing from the IT industries. Instead, these industrial robots are attracted & valued by the more traditional, financially rewarding industries, described above: transport, audio-visual, education, military, retailing, finance. Baby boomers like myself were self educated in our MBA stuff, before the forced fed industrial robots were mass produced by the educational factories.

[reavertm]

If upstream is 5.21 how is Fedora on 5.73? In any case I hope it includes all this new goodness we have been hearing about.

KDE Relese is split to KDE Frameworks part (think of it as modular kdelibs), KDE Plasma and KDE Apps part.
Frameworks is at 5.74 version at the moment, Plasma at 5.21 and Apps at 20.08.

[Nocifer]

This is a major gripe for me too. It's due to the kernel unable to find the prior driver on disk that's running the kernel module for it. You're probably using Arch or similar which deletes the previous driver when upgrading? AFAIK on distros that don't delete previous versions (they keep the last one around until next driver update to replace it I think, so there's a fallback) it's a non-issue. I could be wrong and it might be the kernel and it's files itself that I'm thinking of, but I'm usually updating graphics drivers at same time as my kernel, one of them is the culprit.

Nope, it's not that. It doesn't break when the kernel is updated due to the modules for the old kernel having been deleted (even though that too isn't much of a problem, since I use a script that after a kernel update keeps all the old modules around and loaded until the next restart), it breaks when the driver itself is updated, because the modules unload during the update and apparently KDE can't handle this kind of mid-session module unloading. This doesn't happen e.g. in Gnome, which can handle kernel and display driver updates out of the box just fine, so unfortunately this problematic behavior is entirely on KDE.

I've used sorting lately and not had any issues personally. I've sorted by name, modified date and type. I assume it is fixed? I'm on Manjaro.

Nah, I've tested it on a recently updated OpenSUSE Tumbleweed installation and it still doesn't work. Here's my bug report in case you're interested to better understand what exactly I'm talking about. And there are more, both older and newer, bug reports about sorting being broken in various ways, either not applying correctly or not applying at all. You can just search for "sorting" in the dolphin section and you'll find plenty of them.

Yeah that'd be nice to see improved, I remember looking into CJK but that issue you describe IIRC was some finger pointing about who's responsible for input handling, which I think was Qt, but Qt would say it's Plasma, and there might have been a third vendor in the mix (might have been X11/Wayland).

Yeah, there was some light finger pointing the last time it was seriously discussed (it was more a debate about who - the display server or the IMEs themselves - should handle some internal technical stuff needed for proper integration) but that was back in 2017 - now we're in 2020, and this much needed feature did not even manage to enter the spotlight as a main goal for KDE's 2020 roadmap. I can only hope that, because proper Wayland support is the project's main focus, and because current IMEs completely break on Wayland, fully and properly supporting Wayland means that first rate CJK support will eventually be on the menu.

[Vistaus]

Some nice improvements and fixes for Wayland. I've tried to use Plasma 5.20 Beta from kde-unstable in Arch Linux, but so far it will just crash after 30 seconds with radeonsi and kick me out of my Wayland desktop session back to sddm. I'm sure it will be fixed in the next days...

Been waiting for that fix on Intel hardware for a couple versions now, so I wouldn't get my hopes up...

[Vistaus]

So if it will be started by systemd, then maybe we can use systemd to restart it in case of problems and systemd can put it in it's own slice / cgroup to have higher priority than other processes, so it's always faster and smoother than everything else.

I wish they will implement a native control panel for systemd units like Manjaro has done so we have the ability to graphically control systemd stuff also in other distros that use KDE Plasma, not in Manjaro only.
Maybe they can talk to Manjaro developers to upstream their work.

Why would they need to talk to Manjaro when they have already done the work?

https://github.com/KDE/systemd-kcm

[pWe00Iri3e7Z9lHOX2Qx]

KDE Relese is split to KDE Frameworks part (think of it as modular kdelibs), KDE Plasma and KDE Apps part.
Frameworks is at 5.74 version at the moment, Plasma at 5.21 and Apps at 20.08.

And just to add to this, F33 will be on 5.19. You get whatever version was in Rawhide when they branched for the next release. F33 branched on August 11th with Plasma 5.19 in place.

[Danny3]

Why would they need to talk to Manjaro when they have already done the work?
https://github.com/KDE/systemd-kcm

Is that the same as what Manjaro uses ?
If so that's great, they can just take it and include into the normal release.

It would make much more easier to control systemd units on distros like Kubuntu.

[boxie]

Is that the same as what Manjaro uses ?
If so that's great, they can just take it and include into the normal release.

It would make much more easier to control systemd units on distros like Kubuntu.

hrm https://invent.kde.org/unmaintained/systemd-kcm - that unmaintained in the URL makes me think that the answer is "no"