Some months ago, I used KDE Neon, a distro (that they call a non-distro, but come on, it’s a distro) that combines Ubuntu in its latest LTS form (24.04 currently) with the newest KDE software. It used Plasma 5, which had a rocky start but had evolved to be a fantastic, stable, and surprisingly lightweight (given its reputation) desktop environment.
That changed, though, when Neon went to Plasma 6. It wasn’t really their choice; Plasma 5 is based on Qt 5, the toolkit used to build the UI, and Qt 5 was going EOL in favor of Qt 6. Plasma 6, as you have surely gathered, would be based on Qt 6.
When the Plasma 6 update came to Neon, I took a Timeshift snapshot and performed the update. Time to evaluate it and see how it works for me!
I soon found a few disappointments. First, the devs had decided to remove the icons mode for the system settings (which resembled Microsoft’s Control Panel). The icon titles had become headings in a sidebar list, using the same icons, but in smaller form.
I always preferred the icons mode. I can find every thing I need to by position of the icon and the nice big icon. I knew where everything was without really thinking. The new sidebar format (which was not actually new at all; it had been there as the default in KDE for some time, but I always changed it to icons) does not lend itself to the same kind of rapid recognition spatially. You can kind of get a muscle memory feel for how far down the list any given thing is, but that’s it, and the icons are smaller and don’t grab my attention the same way.
This seems like another step back in usability and customizability for the alleged purpose of reducing maintenance, but where the actual reduction in code is trivial. This is KDE we are talking about, the desktop whose raison d’etre is to have as many options as possible, so that it is nearly infinitely customizable.
Annoying, but tolerable. I’m not in the settings so much that this is a deal-breaker.
My taskbar widgets also did not work with Plasma 6. I could port them, I think, but if I don’t have to, I would rather not.
Otherwise, Plasma 6 was rather unremarkable. It wasn’t meant to be a big departure from Plasma 5; they were upgrading because the underlying Qt toolkit was forcing their hand, not because they had in mind any big upgrades. Qt 6 (as far as I recall) promised better Wayland support, but as I was not using Wayland, that didn’t excite me.
Some time ago, I wrote an editorial of sorts over the state of the libinput driver for mice, touchpads, touchscreens, keyboards, and other input devices. The lead dev was of the opinion that there was a singular “correct” configuration that would please everyone, and he claimed that the older synaptics driver (named after the touchpad maker, but not only for Synaptics pads) had gotten so complex that it was untestable, and that the myriad options was an admission of defeat, that it meant the devs were unable to get it right, so they chose instead to give the users the tools to get it right (in their own use) themselves.
If there is one notion I have emphasized since my Windows days, it is that one size does not fit all. The search for a singular configuration that will please everyone is a fool’s errand, and to refuse to provide all but the most basic customizability features (because anyone who finds the touchpad to not be great is meant to file a bug and have them fix the issue) is a mistake, because (again) one size does not fit all.
For years, I have disabled the default libinput driver for the touchpad and used the older synaptic driver. Even though synaptics was allegedly untestable because of its complexity, and libinput was the solution, the several-years-unmaintained synaptics remained superior for my own use.
In time, I learned that libinput had added a custom acceleration curve. This was the big thing I was missing! I like a hefty amount of acceleration, and the option for acceleration they provided was woefully insufficient. Others prefer no acceleration at all, and bristle at the very idea of it. How can one hope to find “the one config to rule them all” when some people want none of a feature and others want a metric ton of it?
I did write about that positive change with libinput. They still stubbornly will not allow the user to turn off the palm detection, which I would like to do, but they’ve tamed it to the point that it is tolerable. But why settle for ‘tolerable’ when you can have ‘ideal?’
That question applied to my choice between Plasma 5 and 6 too.
So, at that point, finding no overriding reason to tolerate the small issues with Plasma 6, I decided to let it bake a while longer, and I migrated to Kubuntu 24.04, which is a LTS release, and as such is built on the final Plasma 5 LTS release.
I’ve been using Kubuntu 24.04 for a while now, and it’s much like Neon under Plasma 5 used to be, which is perfect.
Then, one day, I downloaded an update for Waterfox G, and the first time I downloaded a file, the browser became unresponsive for at least half a minute.
Oh no. I’d seen that before.
This has long been how Firefox and its brethren behave saving a file using the XDG desktop portal in Plasma. The desktop portal was made to allow distro-agnostic Flatpak applications to use the native file chooser dialog and other stuff from the native OS so that it would blend in nicely. Previously, Firefox and its derivatives always used the GTK+ file picker, even though Plasma is not one of the desktop environments that uses GTK+. I find the GTK+ file picker to be quite annoying, as the Gnome devs insist on dumbing things down to an infuriating level (even to the point of removing the filename/path input text box from the load dialog. You have to know the secret control key combo to be able to get it. When they were asked to make the existence of that text entry field discoverable, the GNOME devs said no, it’s not a real feature, but more of an Easter egg for those who know about it.
A key feature like a text input box for file load is an Easter egg. That sums up my problem with the GNOME dev attitude quite well, I think. It shows in their product in many ways, unfortunately. That is one reason I use KDE, based on Qt, not GTK+ (GNOME ToolKit Plus).
The desktop portal, if it works perfectly, is a great solution to this issue of making an application blend in, even if that application is not in a Flatpak format. But the Flatpak devs (whom are either the GNOME devs or are affiliated with them by virtue of both being funded by Red Hat) insist it is not for native applications, only Flatpak (and maybe other competing formats, like Ubuntu’s Snap).
Apparently, they put in some code to block the portal from working with native applications. I don’t know if they still do that or not. At some level, someone was patching the code to re-enable it with native programs, but I never looked into it closely enough to get the full story. What is important to me is how it works.
How it works in Firefox (and Waterfox), unfortunately, is not great. The image file preview feature is grayed out and unavailable in Firefox under the portal, and while you can fiddle with it (set the file type to all files, then it becomes available… but you have to do it each time you save a file), it is a pain. And then there is that long period of UI freeze, which goes on for the full duration that the file is downloading, which is really long, because it also slows the download substantially.
I tried it with the KDE Neon .iso (at nearly 2GB if I recall), and the whole time it was slowly downloading, the UI of Waterfox was unresponsive. Not acceptable!
The inadequacy of the desktop portal for Firefox is why OpenSUSE developed a patch set for Firefox that makes the browser work directly with KDE without needing the portal. They include that patch in the version of Firefox they distribute (for non-KDE users, it behaves like regular Firefox). Fortunately for me, the maintainer of the unofficial but main repo for Linux Waterfox had always included that patch in his builds, so they worked perfectly with KDE. All was well!
Until it wasn’t. I looked at the packages in Synaptic (the package manager, not the touchpad driver. The touchpad driver is plural, while the package manager is singular) and I saw that the change was planned for, not a bug or mistake.
I asked about it on Reddit, the official support forum for Waterfox, but the maintainer of the repo (who is also one of the main mods) declined to reply. I sorta can’t blame him; he is probably quite tired of people who think they are entitled to his time demanding that he do this or that because they want it. I had no intention of doing that, but he cannot know that. I tried to word my query carefully, asking what the reason was, and explaining that the integration the patch brought was really a killer feature for KDE users. I assume he is one himself, or else he probably would not have gone through the effort.
Regardless of his reasoning, I am still grateful for his gift to the community in the form of his repo, and I know none of us are entitled in any way to his time.
The thing that really puzzles me is that Chromium works perfectly with the desktop portal. Or as perfectly as any browser does, anyway. The image preview feature works without fiddling around. There is no slowdown of downloads or a UI freeze until it completes. Firefox presumably could fix this; if Chromium did it, so can they, but Firefox has always been inexplicably hostile to KDE.
So, I switched to Vivaldi, intending that to be my main browser. There is a lot to like about Vivaldi, but I soon began to bristle at its Google-designed deficiencies. Chromium was created to serve Google’s interests, not those of the user, much as the Microsoft browsers were created to serve Microsoft’s interests. Firefox is the only one that was community developed and meant to be a public service (though their ability to do so when their funding relies on Google is in question).
The final straw was when I saw the post from Vivaldi devs, to the effect that as soon as Chromium drops Manifest V2 (in order to cripple adblockers; Google, of course, is an ad company), they would make no attempt to restore it, which they brushed off with the claim that it was fine, because Vivaldi has a built-in adblocker (which is very basic and limited compared to the best adblocking addon, uBlock Origin).
Microsoft has long been hostile to open source, as if they believed that if anyone got a look at their source code, the jig would be up, much like it was for the Soup Nazi in Seinfeld when Elaine found his recipes. Google made a big bet that they could completely give the source away under a permissive license and still maintain control of it to be able to shape the web in their own image. The open-source bit gives them a huge excuse if the US DOJ comes after them as they did Microsoft decades ago, while not providing any actual protection from the Google hegemony.
A browser without uBlock is not usable.
I had an idea. Perhaps the implementation of the desktop portal backend (the KDE part) was better under Plasma 6, since that is where the active development is taking place. I let one of my other laptops (not in the sig) that was still on Neon to upgrade to Plasma 6, and I tried out the portal.
What do you know… it works! The image preview works fine, and there was no slowdown noted after a download. I even copied my huge downloads directory over to do an apples to apples comparison, and there was no slowdown.
Ok then.
I did a Timeshift and a Veeam backup of the system, then rolled back the Timeshift to the last time I had Neon on this PC (my Dell XPS 13). That was back when it was still based on Ubuntu 22.04, so I let it update to Plasma 6 first, then to Ubuntu 24.04. After some dependency nightmares were resolved, I had Plasma 6 under Neon all ready.
The image previews work (yay!), but for some reason the hang when saving is still there. This hang is consistent on my other PCs except the one I used for the test. It is my only one with an AMD Ryzen CPU, but that shouldn’t be it (but it could be anyway).
Also annoying in this new version was that the bug that was causing my desktop icons to reset themselves each time I log in had not gotten any better. I had hoped it would be, but alas, no. Apparently a fix is in the works, but it was not here yet.
I had another idea. What if I tried the Flatpak version of Waterfox, thus allowing the desktop portal to work as intended?
I installed the Flatpak version to find out. Lo and behold, it was working quite well! The image previews worked (still grayed out, but at least the box was ticked), and there was no UI hang.
On a whim, I decided to start a Wayland session and see how that looked.
The font size was bigger on everything, so I decreased it, and otherwise it looked about the same. But here’s the neat part– the desktop icons stopped resetting. They remain right where I want them!
Hmm… could it be that Wayland is mature enough for me, the guy who would be more inclined to say, “Out with the new, in with the old?”
I looked up how to set the custom accel profile in Libinput, and I worked out a config that is almost perfect. I will try to get it all the way perfect later on, but it’s mostly there. I found that I had to use udev rules to set the config options, so I did that. and it worked! After a reboot, my custom accel profile is still working.
That was my chief objection to Wayland. My next biggest objection was that it forbids running as root, as that is insecure. KDE tried to end the practice before the replacement was ready, and it led to a user revolt of sorts that had them backpedaling and providing a somewhat secret way to put “open as root” back in. Wayland, of course, would not be so forgiving.
I was pleased to find that the admin mode (which also been added to Plasma 5 by then, but since I had root, I never used it) was a reasonable substitute for “open as root.” I’ve been able to complete every admin task without having direct root.
So, on to other issues.
One obvious issue I had with Waterfox under Wayland was that the text was microscopic. That was fixed by resetting the PixelsPerPx pref in Waterfox to -1 (default), but the mouse pointer remained tiny.
After some messing around, I found the answer. I merely had to reinstall the GTK+ backend for the desktop portal once again. By default, Neon comes with this, right along with the Plasma backend, but I had tried removing the GTK+ one to try to solve the UI lag during a download. Once it was back, the mouse arrow was back to normal.
Waterfox is now working nicely in the Flatpak, and as an added plus, it is sandboxed, providing an extra layer of security between the browser (the most common malware vector into a PC) and the rest of the system. On Windows, this can be provided by applications like Sandboxie, but I got it for “free,” so to speak, while trying to fix something else. Linux browsers are unlikely to be attacked at present, but they could be targeted more in the future.
The tray widget that I was using to troubleshoot power usage still does not work under Plasma 6, but I don’t need it anymore, so I can live with that. Someone had done a better job than I had done as far as creating a custom narrow bar graph setting for the system tray (which I use for a per-core CPU usage display), so that’s great.
Unfortunately, the power options don’t work as they should on this version of Plasma either. I have it set to turn the keyboard lights off and dim the screen a bit when unplugging the AC adapter, but it only does the keyboard light. In Plasma 5, it only did the screen dimming. It has not worked on any of my PCs in my sig, all three from different makers. My script I used to take over the dimming functions still works now, fortunately.
After the upgrade, Neon began (annoyingly) accepting fingerprints for unlocking the screen after it had been manually locked or the usual lock after resuming from sleep. I use fingerprints to streamline sudo requests, not for login! I could find no option to configure this,k and I think it is a bit presumptuous to change the way fingerprints are accepted from previous versions (it could be that this is the first one officially to have fingerprint support, so they don’t see it as having had anything to compare the new way to). I figured out, through trial and error, how to get it to stop accepting fingerprint swipes as an unlock, and it took even more messing around to get it to stop prompting for a fingerprint swipe or a scan of a smart card (this PC has no smart card reader). The short answer is to look in /lib/pam.d and /etc/pam.d.
I also kept having Waterfox spontaneously act like I had hit the back or forward buttons on the browser. After the first time or two, I realized that Firefox was interpreting touchscreen-type swipes on the touchpad as a “go to previous” or “go to next” command. I don’t want or need that! The answer was to change the pref widget.disable-swipe-tracker to true.
I think that’s it. As far as I can tell, I have a fully functional Plasma 6 setup on Wayland using the Flatpak Waterfox-G and (gasp) libinput. I’ve been more or less opposed to all those things before (I prefer Flatpak to Snap, but I still prefer native applications), but they are all working now.
Whew, that was a long one. Congrats and thanks if you got this far!
Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)
