These goals are big, high-level goals. Think “focus on large strategic topic X” more so than “fix my pet bugs A, B, and C”.
And it’s up to the KDE community to choose the goals! Up to you, up to me, up to all of us. They will then be voted on, with the top three informing KDE’s overall direction for the next two years.
KDE needs you! Your fresh ideas, your contributions, your budding leadership talent. But not your imposter-syndrome-driven fear of coming out of your shell. 🙂 Overcome that!
I’ve now been the champion for two goals: “Usability & Productivity” and “Automate & Systematize Internal Processes“. I’d count the first as pretty successful; the second, less so. So at this point I feel like I have a pretty good idea of what works and what doesn’t, and I’d like to use that knowledge to help others submit their own high-quality actionable goals.
Here’s what works, in my experience:
Articulate an immediately obvious large problem or aspiration. If you’ve spent any time in KDE or using KDE software, you’ll have encountered stuff that could be better. Big stuff. That’s the topic to write a goal around! Not “Discover is too slow to refresh when I launch it” but rather “First-class software delivery UX” (you can steal that).
Have a technical lead and a communications lead. They can be different people, but you need both. Only have a tech lead? Not enough communication, people forget about it, don’t join, and the tech lead burns out. Only have a comms lead? Not enough work happens and the goal limps embarrassingly towards the finish line.
If you propose a goal, be the tech lead. You can be the comms lead too. But you should be prepared to be the tech lead. It’s much easier to recruit people to do other things than it is to recruit a tech lead to do a ton of work on your behalf that you can’t to yourself.
Don’t bite off more than you can chew. If you can’t be the tech lead on your idea, scale it back or change its scope so that you can be the tech lead. This doesn’t mean you have to know how to do everything. It just means you can do a big chunk of the technical work, and at least understand the concepts of the things you can’t personally do.
It’s really fun, and you end up having a huge impact on how awesome KDE is.
I’ve submitted a goal proposal about improving KDE’s documentation. Credible choices make voting useful, but right now we have as many submissions as goal slots, and that’s no fun. So get yours in too!
By now, many of you have probably seen Linus Tech Tips’ “Linux is Easy, right?” video?
The TL;DW version is that yes, things are mostly pretty easy, and the tasks they’re having trouble are becoming become less and less common over time… but pain points remain for the “prosumer/technology enthusiast” crowd: folks who are moderately to very technical, but aren’t software developers.
KDE comes out pretty well, with one exception: network shares.
Network shares.
Yes, network shares.
Still. In 2026!
What the heck is going on here? How is this not a solved problem? Let’s talk about it today.
How it works in KDE’s software
When you access a network share from Dolphin’s built-in network share browser, it doesn’t get mounted as a local path somewhere; Dolphin is connecting to the share using its own communication protocol: smb://, nfs://, or similar.
This is fine for KDE apps; they can use those communication protocols to access files when you double-click them on network shares you’ve accessed using Dolphin.
Everything works.
When you double-click a file on a network share and it opens in a non-KDE app, at that point something called kio-fuse (that we did a ton of work to build a few years ago) secretly creates a FUSE mount of the share in the background, and passes the app a local path to the file on the secret FUSE mount.
This way, the non-KDE app opens the file from a local path as it expects, and everything still works.
No it doesn’t, you liar!
You caught me! Everything works if you open the file from Dolphin… but what if you need to access a file on the share from the “open” dialog in an app, or save a file to the share using the “save” dialog in an app?
Well, then things get more complicated.
If it’s a KDE app, the standard KDE open/save dialog knows how to access the network share so you can open or save new files there. If you’ve created a bookmark for the share in your Places panel (which is our documented recommendation in KDE Linux), it’s already right there; simply click on it to connect to the share, and navigate to the desired file or location. Easy peasy, everything works.
A bookmarked network share for my living room HTPC. Accessible in the same way from Dolphin and KDE open/save dialogs. Works great!
Sounds great! So where’s the complication? Let’s move on.
If it’s a non-KDE app that uses the KDE open/save dialog, it’s the same deal: access the share from the dialog, everything works. Example apps are VLC and LibreOffice (when run with the Qt backend). Still no complication…
If it’s a non-KDE app that uses the portal-based open/save dialog, then everything is lovely here too. The app asks the XDG Desktop Portal for an open/save dialog; the portal offers up the KDE dialog; everything works. In this respect, Flatpak has been encouraging adoption of the portal-based open/save dialogs, which produces a really nice experience: KDE users get a KDE open/save dialog in almost every Flatpak app — something we’ve all wanted for years!
But now we come to the problem:
If it’s a non-KDE app that uses its own non-KDE open/save dialog… then everything becomes terrible. Its dialog will not see any bookmarks you’ve added to the KDE dialog, and will expect you to have the share mounted locally somewhere. Even if kio-fuse created a mount, the non-KDE dialog doesn’t show it nicely in its sidebar! You have to know the secret location of the mount (/run/user/1000/kio-fuse-[something]) and use the dialog to navigate there manually.
If these apps are packaged traditionally, that’s bad enough. If they’re Flatpaks, it’s worse: they have to be packaged with a hole in the security sandbox that allows them to access the kio-fuse mount, or else you can’t access it even if you know it exists and navigate there manually. Most do this for the location where GNOME’s own system mounts shares… but not for the location where kio-fuse mounts them — nor the location of any shares you’ve manually mounted, for that matter.
In addition, the GTK open/save dialog’s built-in network browsing feature is broken unless the app’s Flatpak packaging pokes another sandbox hole for network access — many don’t! And custom dialogs may not even have this feature at all.
What a mess. Unfortunately, as of June 2026 (if you’re reading this later, please verify), apps in this unfortunate situation include some important ones like Blender, GIMP, LibreOffice (from Flathub or with the GTK backend), OnlyOffice, Inkscape, Audacity, DaVinci Resolve, and Gedit.
So, that’s bad.
If it’s a command-line tool or daemon, then everything is terrible in the same way. All previous use cases involved GUI tools accessing or mounting the network share; until and unless that happens, there’s nothing for CLI tools to see. It’s as if the share doesn’t exist. Something would need to mount the share at login. That something usually ends up being driven by changes to /etc/fstab that a random internet tutorial walked you through.
Why not just mount stuff the old-fashioned way using /etc/fstab?
Well, there are a few problems with this — the first one being that /etc/fstab is root-owned, so using it to mount a network share requires administrator privileges. That’s not gonna fly on multi-user or administrated systems.
You could work around this by using a GUI tool that can modify that file using Polkit, and then ship a Polkit rule to auto-allow this app’s requests to modify the file — even for non-admin users.
If it’s a password-protected share, you’ll also have to store the credentials in plaintext somewhere; there’s no provision for storing them in an encrypted password storage system.
This makes a mockery of security, but even if that’s acceptable, it turns out there isn’t just one way to mount a network share using /etc/fstab, but rather about twelve thousand ways. Every online tutorial gives you a slightly different set of steps, and if you don’t do it just right, you’ll end up with a mount that isn’t writable, or delays the boot process if it’s not accessible at that time, or causes apps to hang and freeze if it becomes inaccessible later, or other non-obvious problems that can be really “fun” to troubleshoot.
It’s not impossible to do this properly, but you have to know what you’re doing. So you really want this file to only be touched by a person or organization that qualifies, and to not make changes to it that you don’t fully understand.
Time for full disclosure: KDE e.V. is contracting with my company Techpaladin Software to run this part of the project. Network shares represent a significant paper cut, and I’m really excited to be a part of the process to finally get this topic sorted.
I’m not micromanaging the project; frankly, I don’t have the time, even if I wanted to! So my involvement so far has mostly been to put smart people in charge, gather them together into a (virtual) room where they can be productive, and make sure they’re adequately funded! Which is what I’ve done, and and I have every confidence in the team.
Here are some of the ideas under discussion:
Have Dolphin and open/save dialogs automatically create temporary bookmarks for recently-accessed network shares, maybe in the “Recent” section. This would eliminate the step of manually bookmarking transiently-accessed shares.
Have Dolphin and the open/save dialogs create a FUSE mount for each share they access immediately after accessing it, rather than the first time a file from the share is accessed in a non-KDE app. This would solve the problem for CLI tools — provided the share is manually accessed at least once beforehand.
Either expose the FUSE-mounted share at a location on the system that lets the legacy GTK open/save dialog see it by default, or submit patches to GTK to let the GTK open/save dialog to see kio-fuse-created network share mounts at their current location. This would extend that fix to non-Flatpak apps using the legacy GTK dialog.
If the user manually bookmarks a network share, have kio-fuse automatically create a mount for it on login, similar to “mapping a drive letter” on Windows. This would remove the caveat “…provided the share is manually accessed at least once beforehand.”
Submit patches for apps on Flathub that still use this legacy dialog that let them see the location where kio-fuse mounts network shares. This would extend the above fixes to these apps’ Flathub packages.
Submit patches to port remaining apps to use the portal-based open/save dialog. This would reduce the number of GUI apps that need the above fixes in the first place.
Standardize the location and mount arguments for these FUSE mounts so you never end up with GNOME and KDE apps FUSE-mounting the same share to different locations. That’s just ridiculous! I’m not sure how politically possible this is, but it would be nice to reduce duplication.
Look into using systemd mount units as the underlying implementation if systemd is available, and use the current kio-fuse implementation as a fallback only on systems without systemd. This would let us use an already standardized system and the more performant kernel drivers for remote filesystems. And it might be more feasible than #7.
Lots of ideas. Preliminary work has already started, and I expect it to be an ongoing area of focus in the coming months.
So hopefully soon this topic will finally be in the rear-view mirror. I think it’s clear that KDE is not yet 100% there on network shares, and we can do better. And we will!
X11 is in the news again, so I thought it would make sense to be clear about the Plasma team’s plans for X11 support going forward.
Current status: Plasma’s X11 session continues to be maintained.
Specifically, that means:
We’ll make sure Plasma continues to compile and deploy on X11.
Bug reports about the Plasma X11 session being horribly broken (for example, you can’t log in) will be fixed.
Very bad X11-specific regressions will probably be fixed eventually.
Less-bad X11-specific bugs will probably not be fixed unless someone pays for it.
X11-specific features will definitely not be implemented unless someone pays for it.
This is actually not too bad; there are relatively few open and fixable X11-specific bugs (0.76% of all open bug reports as of the time of writing), and when I went looking today, there were only two Bugzilla tickets requesting new X11-specific features that needed closing. Most bugs and features are platform-agnostic, so X11 users will benefit from all of these that get fixed and implemented.
Eventually it’s lights out for X11 though, right? When will that happen?
Yes, the writing is on the wall. X11’s upstream development has dropped off significantly in recent years, and X11 isn’t able to perform up to the standards of what people expect today with respect to HDR, 10 bits-per-color monitors, other fancy monitor features, multi-monitor setups (especially with mixed DPIs or refresh rates), multi-GPU setups, screen tearing, security, crash robustness, input handling, and more.
As for when Plasma will drop support for X11? There’s currently no firm timeline for this, and I certainly don’t expect it to happen in the next year, or even the next two years. But that’s just a guess; it depends on how quickly we implement everything on https://community.kde.org/Plasma/Wayland_Known_Significant_Issues. Our plan is to handle everything on that page such that even the most hardcore X11 user doesn’t notice anything missing when they move to Wayland.
Why are you guys doing this? Why don’t you like X11 anymore?
The Plasma team isn’t emotional about display servers; it’s just obvious that X11 is in the process of outliving its usefulness. Someday Wayland will be in this boat too; such is the eventual fate of all technologies.
In addition to the fact that Wayland is better for modern hardware, maintaining code to interact with two display servers and session types is exactly as unpleasant as it sounds. Our resources are always limited, so we’re looking forward to the day when we can once again focus on programming for a single display server paradigm. It will mean that everything else can improve just a little bit faster.
Regardless of when you pull the trigger, isn’t it premature?
Most major distros have already moved their Plasma sessions to Wayland by default, including Arch, Fedora, KDE neon, Kubuntu, and generally their downstream forks. Several others whose roadmaps I’m familiar with plan to do so in the near future.
At this point in time, our telemetry says that a majority of Plasma users are already using the Wayland session. Currently 73% of Plasma 6 users who have turned on telemetry are using the Wayland session, and a little over 60% of all telemetry-activating users (including Plasma 5 users) are on Wayland.
Interestingly, the percentage of Plasma 6 users on Wayland was 82% a month ago, and now it’s down to 73%. What changed? SteamOS 3.7 was released with Plasma 6 and the X11 session still used by default! Interestingly, since then the Wayland trendline has continued to tick up; a month ago the percentage of Wayland users dropped from 82% to 70%, and now today it’s up to 73%.
So you can see that to a large extent, this is up to distros, not us. It wouldn’t make sense for us to get rid of Plasma’s X11 support while there are still major distros shipping it by default, and likewise, it won’t make sense for us to keep it around long after those distros have moved away from it.
Regardless, Wayland’s numbers are increasing steadily, and I expect upward bumps when the next Debian and Kubuntu LTS releases come out, as both are currently planned to be Wayland by default.
Now, is Plasma’s Wayland session perfect? No. (what is?)
Is it better than the X11 session in literally every way? Also no.
Is it better in most ways that matter to most people? The numbers say yes!
Well I’m not a most people! I’m me, I’m an individual! I’m not a number, I’m a free man!
That’s fine, and you’re the reason why we’re still maintaining the X11 session! We’re going to try very hard not to to get rid of it until you’re happy too.
Ultimately that’s the goal here: make everyone happy! This includes people who have mixed-DPI/refresh rate multi-monitor setups or laptop touchpads, as well as people using AutoKey or graphics tablets with dials on them. Long transitions like this are tough, but ultimately worth it so that we all get something better in the end.
A few days ago I returned home from a wonderful Plasma sprint in Graz, Austria. Between COVID-19 and there being no Plasma sprint last year in favor of the Goals mega-sprint, this was actually only my my third in-person Plasma sprint! So I was very excited to attend. There’s much to talk about!
This was actually not the location, appropriate name notwithstanding!
Sprints are often said to come in two flavors: “talking” sprints, which are mostly about discussing big topics; and “working” sprints, where folks write lots of code. This one was a bit of both — a good mix, I think.
For my part, I wanted to talk about some big topics and see if we could get them unblocked. And talk about them we did! There were many more discussions besides these, but here’s a summary of the ones I led:
Plasma LTS
It’s no secret that our Plasma LTS (“Long-Term Support”) product isn’t great. It really only means we backport bug-fixes for longer than usual — usually without even testing them, since no Plasma developers enjoy living on or testing old branches. And there’s no corresponding LTS product for Frameworks or Gear apps, leaving a lot of holes in the LTS umbrella. Then there’s the fact that “LTS” means different things to different people; many have an expansive definition of the term that gives them expectations of stability that are impossible to meet.
Our conclusion was that the fairly limited nature of the product isn’t meeting anyone’s expectations, so we decided to not continue it. Instead, we’ll lengthen the effective support period of normal Plasma releases a bit by adding on an extra bug-fix release, taking us from five to six.
We also revisited the topic of reducing from three to two Plasma feature releases per year, with a much longer bug-fix release schedule. It would effectively make every Plasma version a sort of mini-LTS, and we’d also try to align them with the twice-yearly release schedules of Kubuntu and Fedora.
For some background, last Akademy we decided to postpone making this schedule change until all the KDE items on the “Wayland known significant issues” wiki page are addressed. During the sprint, we took another look and found the list much shorter than it was last year, with most remaining items in progress or nearing completion! So we agreed to revisit the topic again around this year’s Akademy in about 4 months (reminder to submit a talk!).
I hope that by then we’ve either got everything done, or can consider it close enough that we can pull the trigger on the new schedule anyway — the latter outcome being what we did for the Wayland-by-default rollout.
However, the concept of “Long-Term Support” doesn’t go away just because we’re not giving that label to any of our software releases anymore. Really, it was always a label applied by distros anyway — the distros doing the hard work of building an LTS final product out of myriad software components that were never themselves declared LTS by their own developers. It’s a lot of work.
So we decided to strengthen our messaging that users of KDE software on LTS distros should be reporting issues to their distro, and not to KDE. An LTS software stack is complex and requires a lot of engineering effort to stabilize; the most appropriate people to triage issues on LTS distros are the engineers putting them together. This will free up time among KDE’s bug triagers and developers to focus on current issues they can reproduce and fix, rather than wasting time on issues that can’t be reproduced due to a hugely different software stack, or that were fixed months or years ago yet reported to us anyway due to many users’ unfamiliarity with software release schedules and bug reporting.
3rd-party content and theming
We’ve had some difficulty with the UX for how users get 3rd-party content, and what it does to their system once they’ve gotten it. Many folks will remember the issue last year when a defective 3rd-party Global Theme caused user data loss. It was Very Bad™.
The issue here is that QML-based theming is just inherently dangerous because QML is code; there’s not really a way to make QML theming safe, so we’re working on moving away from it. David Edmundson wrote about this recently, too.
So far we’ve already removed QML-themability from the lock screen (a component that’s very sensitive to stability and security needs!), and during this sprint, we hit the OSDs too. We also made plans to remove QML-themability from splash screens and login screen themes, and instead you’ll simply be able to choose custom images.
However, some things will always have to contain QML code, like 3rd-party widgets and wallpaper plugins. For these, we devised a plan to sandbox them so they can’t blow up the world if they misbehave. This will also make Global Themes safe, since Global Themes can include them. I wasn’t able to follow all the details of the proposed sandboxing system, so others will have to fill in the blanks with their own blog posts!
Finally, we talked about the distribution channel of https://store.kde.org, exposed via the “Get new [thing]” dialogs sprinkled throughout System Settings and KDE apps. What some might not know is that this distribution channel is not actually owned by KDE; it’s simply a themed front-end to https://pling.com. And that’s one of the issues: people think this is owned by KDE, and it’s not! Some other concerns included the lack of approval-required moderation for new content with stability or security implications; lack of automatic linting for content to make sure it’s valid; inability to specify a minimum Plasma version for QML-based content; and the place being sadly flooded with low-effort AI-created junk. We also talked about some UX issues in these dialogs and in Discover, and how we can address them.
We brainstormed what our ideal 3rd-party content distribution mechanism would look like if we were creating one from scratch, and the degree to which our current UX does and doesn’t approach it. I’ll be reaching out to the folks behind Pling to see if we can work on any improvements there so we can make reality converge more with our desires!
Activities
Activities has been in a weird place for a long time now. It’s a feature that’s somewhat difficult to explain in an elevator pitch, and with a more limited scope than you might expect. We all pretty much agreed that it’s not ideal, and not as useful as it could be.
So we brainstormed many alternatives, taking into account feedback and experiences from people at the sprint who currently do use Activities, or would like to if it met their needs.
Something that came up over and over again was the desire to use certain apps differently in different Activities. For example in your “Home” Activity, you could have your email client set up to only show your home email accounts, whereas in your “Work” activity, you could have the same app set up with only the work email accounts, or with both. But it would be the same email client app in each Activity, just configured differently!
This functionality right now needs to be provided by each app implementing its own “profiles” or “sessions” feature — and of course, most don’t. So an idea that stuck was for us to make this into a system service that can basically bolt the functionality of multiple profiles/sessions onto any app! This would be easiest for containerized apps that already have their own separate location for configuration data, so this is where we’ll start. But it’s possible we’ll also be able to open it up to un-containerized traditionally-packaged apps too, using Firejail or another similar technology.
We thought this feature would be useful even outside of Activities, so our conclusion thus far has been to build it first! After it’s in production and the kinks have been worked out, it would then become the basis for the Activities system’s new scope: “configure and use your apps and virtual desktops differently in each Activity.”
There are no timelines for any of this yet; it’s still in the “turn a discussion into a plan” phase.
Telemetry
There was broad agreement that the status quo is not ideal: we collect very little data from people who have opted in (because it’s off by default), and we don’t have a path towards changing what data we collect in response to newly-discovered questions we’d like answered.
For example, let’s say we want to remove a very niche KWin effect that we think probably nobody’s using. Right now, we have no way of knowing how many people have it turned on, and of them, how many people are actually using it — let alone reaching out to ask them why! So we have to just go by gut feelings when we make that decision, or get spooked and not do it at all.
So we decided to change the way we collect telemetry to be more like the common and successful Steam Hardware Survey. Our telemetry UX will be the same: people will see a dialog window asking them to participate in the survey, and in there, they’ll see what data will be collected. They’ll have the opportunity to say yes, say no, or turn it off forever. And for each survey, we can tailor the data collected to what we actually want to know! So we could have it collect information about that KWin effect, and it could even prompt the people using it to write a little bit of text explaining why.
We also discussed how the current place to view collected data is not ideal. Right now there’s a GUI app which is slightly broken, and a web page you have to type raw SQL queries into to see anything besides the default visualizations. Not ideal! We brainstormed a better web UX so we can make better use of the data we do currently collect. We also agreed that we want to make the aggregated data public, just like Valve does with the results of the Steam Hardware Survey.
In addition, I got in a lot of hacking time between discussion sessions, which felt useful. Being able to sit down with other people unblocked some work, both mine and theirs, as a result of some productive face-to-face conversations! And I got to see a lot of old friends again, and meet a few in person for the first time. The city of Graz was lovely too — such a sensible and humane-feeling place.
Thank you to TU Graz for hosting us for this sprint, to Techpaladin Software for sponsoring my travel and lodging costs, and to Harald Sitter for organizing everything!
It’s been several years since I announced Plasma’s 15-minute bug initiative, and you can see the weekly numbers in every week’s “This Week in Plasma” post. Today I thought I’d share a high-level recap of where we’re at as of the first quarter of 2025.
In short: really good. We dipped below 20 bugs for the first time today, with the number currently standing at 19! This is good progress; it was at 32 during last year’s update.
But wait a minute… 13 bugs in a year? That actually sounds pretty pathetic.
Well here’s the thing: we’re adding more bugs to the list all the time. So it’s basically a “oh wow, we’d better fix this soon before people notice it” list, and newly-discovered significant issues in git master are commonly marked as HI priority and fixed before they reach users — otherwise known as “QA”. 🙂
Last year, the total number of lifetime fixed 15-minute bugs was 231. Today, it’s 413. So actually, we fixed 182 15-minute bugs in the past year or so, and reduced the total number of outstanding 15-minute bugs by 13. With only 19 left, that means we’ve fixed over 95% of all 15-minute bugs ever!
If you look at the remaining bugs, some patterns emerge:
Hardware-specific issues (e.g. only certain ASUS laptops, or only certain screens)
Use of common though non-default settings (e.g. changing the scroll speed, hiding tray icons of Electron-based apps)
Intensive use of the system (e.g. filling the entire panel up with icons-only Task Manager icons, docking and un-docking a laptop to an external screen with carefully-curated window arrangements)
Random and unreproducible crashes (if they were reproducible, they’d have been fixed ages ago!)
And some egregious bugs that just need to be fixed! (we’re working on them)
How you can help
As always, help work on the existing 15-minute bugs if you can! If not, it’s always useful to work on bug triaging, so that more of those issues that will eventually become 15-minute bugs can get discovered earlier. Another impactful way is to donate to KDE e.V., the nonprofit that supports KDE on a ridiculously small budget. Prior donations have allowed KDE e.V. to recently start the process of hiring a Plasma developer, so it’s not a black hole!
This will be a boring one, sorry. 🙂 Basically a “JFYI” for people interested in Plasma’s release administration.
A while back, there was a discussion about moving Plasma to a twice-yearly release model, to better align with discrete release distros that also have two yearly releases — mostly Fedora KDE and Kubuntu.
We discussed this at last year’s Akademy and decided not to do it yet, based on the reason that a faster release schedule would help get important Wayland improvements to users more quickly, given that we’re trying to polish up our Wayland session at high speed. We agreed that once the Wayland Known Significant Issues wiki page is empty, we can re-evaluate.
Until that re-evaluation happens, we decided to instead lengthen our beta release periods from four weeks to six weeks, with new beta releases every two.
Plasma 6.3 will be released very soon, yay! For this release, we remembered to push out the extra new beta releases, but forgot about adding on an extra two weeks to its duration. Oops.
Interestingly, we haven’t gotten many bug reports from users of the Plasma 6.3 beta, which is historically unusual. I’m not totally sure what to make of this. The optimistic assessment is that the release was already great even by the time we shipped the beta! The pessimistic one is that few people showed up to QA it, so lots of bugs got missed (I’m less sure it’s this, but anything’s possible). Either way, it seems like an extra two weeks of beta time wouldn’t have made much difference, so we’re not considering a great loss.
As a result, we’ve decided to try this same approach for 6.4: a four-week beta period, with new releases every two weeks. We’ll see how it goes! If it’s fine, we can keep it, and if it’s not, we can return to the original plan of six-week beta periods. Until then, enjoy Plasma 6.3!
For the past 8 days I’ve been in Berlin for what is technically four sprints: first a two-day KDE e.V. Board of Directors sprint, and then right afterwards, the KDE Goals mega-sprint for the Eco, Accessibility, and Automation/Systematization Goals! Both were hosted in the offices of KDE Patron MBition, a great partner to KDE which uses our software both internally and in some Mercedes cars. Thanks a lot, MBition! It’s been quite a week, but a productive one. So I thought I’d share what we did.
If you’re a KDE e.V. member, you’ve already received an email recap about the Board sprint’s discussion topics and decisions. Overall the organization is healthy and in great shape. Something substantive I can share publicly is that we posed for this wicked sick picture:
Moving onto the combined Goals sprint: this was in fact the first sprint for any of the KDE Goals, and having all three represented in one room attracted a unique cross-section of people from the KDE Eco crowd, usability-interested folks, and deeply technical core KDE developers.
Officially I’m the Goal Champion of the Automation & Systematization Goal, and a number of folks attended to work on those topics, ranging from adding and fixing tests to creating a code quality dashboards. Expect more blog posts from other participants regarding what they worked on!
Speaking personally, I changed the bug janitor bot to direct Debian users on old Plasma versions to Debian’s own Bug tracker—as in fact the Debian folks advise their own users to do. I added an autotest to validate the change, but regrettably it caused a regression anyway, which I corrected quickly. Further investigation into the reason why this went uncaught revealed that all the autotests for the version-based bug janitor actions are faulty. I worked on fixing them but unfortunately have not met with success yet. Further efforts are needed.
In the process of doing this work, I also found that the bug janitor operates on a hardcoded list of Plasma components, which has of course drifted out of sync with reality since it was originally authored. This causes the bot to miss many bugs at the moment.
Fellow sprint participant Tracey volunteered to address this, so I helped get her set up with a development environment for the bug janitor bot so she can auto-generate the list from GitLab and sysadmin repo metadata. This is in progress and proceeding nicely.
I also proposed a merge request template for the plasma-workspace git repo, modeled on the one we currently use in Elisa. The idea is to encourage people to write better merge request descriptions, and also nudge people in the direction of adding autotests for their merge requests, or at least mentioning reviewers can test the changes. If this ends up successful, I have high hopes about rolling it out more broadly.
But I was also there for the other goals too! Joseph delivered a wonderful presentation about KDE Eco topics, which introduced my new favorite cartoon, and it got me thinking about efficiency and performance. For a while I’d been experiencing high CPU usage in KDE’s NeoChat app, and with all the NeoChat developers there in the room, I took the opportunity to prod them with my pointy stick. This isn’t the first time I’d mentioned the performance issue to them, but in the past no one could reproduce it and we had to drop the investigation. Well, this time I think everyone else was also thinking eco thoughts, and they really moved heaven and earth to try to reproduce it. Eventually James was able to, and it wasn’t long before the issue was put six feet under. The result: NeoChat’s background CPU usage is now 0% for people using Intel GPUs, down from 30%. A big win for eco and laptop battery life, which I’m already appreciating as I write this blog post in an airport disconnected from AC power.
To verify the CPU usage, just for laughs I added the Catwalk widget to my panel. It’s so adorable that I haven’t had the heart to remove it, and now I notice things using CPU time when they should be idle much more than I did before. More visibility for performance issues should over time add up to more fixes for them!
Good cat!
Bad cat!
Another interesting thing happens when you get a bunch of talented KDE contributors in a room: people can’t help but initiate discussions about pressing topics. The result was many conversations about release schedules, dependency policy, visual design vision, and product branding. One discussion very relevant to the sprint was the lack of systematicity in how we use units for spacing in the QtQuick-based UIs we build. This resulted in a proposal that’s already generating some spirited feedback.
All in all it was a happy and productive week, and after doing one of these I always feel super privileged to be able to work with as impressively talented and friendly a group of colleagues as this is:
Full disclosure: KDE e.V. paid for my travel and lodging expenses, but not my döner kebab expenses!
A tad over two years ago, I revealed the 15-Minute Bug Initiative–an attempt to improve the out-of-the box user experience for Plasma by focusing on fixing obvious papercut issues. The idea was to crush the meme of “KDE is buggy” the same way we systematically addressed similar complaints like “KDE is ugly” and “KDE is bloated” in years past.
Well, it’s been two years, so how did it go? Let’s talk about it! First some numbers, because we like numbers:
Total number of bugs fixed (because more were added over time): 231
Percent of all total 15-minute bugs that have been fixed: 87.8%
(note if you’re from the future: if you visit those links, some numbers may be different–hopefully lower for the second one and higher for the third one!)
Wow! That’s quite a few. So this initiative looks like it’s been a real success so far! Nevertheless, 32 bug reports remain open, so we can’t declare victory yet. These are some of the stubbornest, hardest-to-fix bugs that require major re-architecting, working upstream, or similarly challenging efforts. Hopefully the pace of improvement seen over these years has managed to convince you that they’ll eventually be resolved as well.
“Wait a minute, Plasma is still buggy AF you n00b”
Keep in mind these aren’t all the bug reports in the world we can fix (there are over 5000 of them for Plasma and Plasma-aligned software alone), just the ones I and some others have deemed to be most obvious to the average user! If you’re not an average user because you have three monitors arranged in a weird shape, each plugged into a different GPU from a different vendor and its own different DPI, scale factors, and custom Plasma panels, plus 4 activities and 9 virtual desktops and 6 internal disks, only half of which automount, and 12 apps set to autostart, and each of them is installed onto different disks, 15 window rules, and finally a custom theming setup including Kvantum themes and Aurorae window decorations… then yeah, you’re probably going to experience some more bugs compared to a more typical user who doesn’t have such a complex setup!
That’s okay. We care about you too, and we do work on those kinds of more esoteric bugs because many of us also have complex setups! But progress here will be necessarily slower, because the complex setups are more varied, more unusual, and harder to debug. And let’s be honest here: those of us with setups like these are experts capable of working around most bugs we find, who really should be helping to investigate and fix them. Admit it, you know it’s true!
But in a way, this is good: it represents Plasma moving from “It’s generally buggy” to “it’s specifically buggy–buggy with only certain less common combinations of settings, rather than buggy in a way that anyone can find within 15 minutes of using a system with its default settings. Improving on that was the point of this initiative.
Next steps
Up until now we’ve been ignoring Wayland-only bugs here, because the Wayland session was not the default one. Well, with Plasma 6 that changes, so all of those Wayland-only issues that meet the loose criteria to be a 15-minute bug will be promoted. Similarly, current 15-minute bugs that are X11-only will be demoted. So sometime in the next few weeks, expect the list to shift around a bit.
Once the number gets down to 0, it will of course go up again periodically as new bugs are found or introduced. But this is great! It means we can whack them as they appear, rather than letting them pile up over time. In this way the list becomes a “rapid response needed” task list rather than a backlog we’re always behind on.
What happens with those development resources once the 15-minute Plasma bugs are under control? I have a plan, first articulated in the original announcement 2 years ago: extend the program to Frameworks bugs! There are quite a few candidates there too. And because frameworks bugs can affect Plasma and our vast app library, quality will go up overall.
Speaking of those apps, once the 15-minute Frameworks bugs are also down to zero or close to it, we can include app bugs. This will finally give us complete coverage! I have a dream that one day, we’ll have a stable and mostly bug-free UI layer and our limited development resources can be focused more on performance work, sustainably-crafted new features, usability, more standardized styling, etc. I think it’s doubtful we can get there while we’re still battling routine bugs all the time.
How you can help
As always, help work on the existing 15-minute bugs if you can! If not, it’s always useful to work on bug triaging, so that more of those issues that will eventually become 15-minute bugs can get discovered. Another impactful way is to donate to KDE e.V., the nonprofit that support KDE on a ridiculously small budget. We’re still running the Plasma 6 fundraiser which represents a great way to donate!
Nothing! That’s the end of the blog post! Go back to what you were doing!
Well, sort of. 🙂 Some of you may be aware that a year or so ago, there was a lot of chatter about what to do with the Activities feature in Plasma 6: change how it works, remove the feature, or leave it be.
There’s broad consensus within the KDE developer community that the Activities feature doesn’t work the way we want it to. Its scope is conceptually unclear, it’s a frequent source of bugs, and it isn’t really maintained. As a result adoption in even our own apps has been low. It was for these reasons that over time we removed many of the entry points for Activities in the UI, and why I eventually proposed removing it entirely.
However the best way to to find out how many people are using something is to remove it! And the second best may be to propose removing it. 🙂 Many people showed up to offer their passionate pleas to keep the feature, explaining what they were using it for. Interestingly, many admitted that the feature didn’t really work very well out of the box and that they had done custom work to bend it to their use cases.
For this reason, several people stepped up to propose an overhaul of how Activities works, taking into account how the feature’s users actually use it. A lot of discussion ensued, and a few changes were merged. One was that Activities migrated from Frameworks to Plasma, which stripped it of its API guarantee and opens the door to us making major changes within the Plasma 6 lifecycle. Another change was to remove the per-Activity power management setting.
Unfortunately not much happened beyond that. As a result the status quo remains largely in effect for Plasma 6: the Activities feature has not been removed, overhauled, or even substantially bug-fixed. It remains a quirky and somewhat buggy DIY feature for adventurous users to build custom workflows around, and today it’s more hidden-away than ever if you don’t want to use it.
However, I don’t expect this to continue in the long term. Once Plasma 6 stabilizes and development resources are pulled off constant bug-fixing, attention will inevitably turn to Activities once again. So consider this blog post notice that the feature is at risk of being eventually removed if people don’t step up to contribute technical work to either fix existing bugs, or else overhauling the feature to work differently.
Personally, I’d like to see Activities morph into a feature whereby each activity has a separate set of settings and config data, but access to all the same user files. On top of that, you would be able to configure individual apps you use in multiple activities (like music players) to use shared settings and config data.This way it would basically be the “profiles” feature that many web browsers have now, but applied automatically to any and all apps you want.
But, like all desires and ideas, that personal idea of mine means nothing without work to transform it into an implementation! So if you use and enjoy Activities, or think you’d like to if they worked differently, please get involved. We’ll need your help if this feature is to remain!
I’ve written some other posts on Wayland recently, and it’s time for another one! Feel free to skip it it you aren’t interested in a discussion of Wayland and platforms.
Many may be familiar with the now semi-famous “Wayland breaks everything!” document written by Probonopd–one of the core AppImage developers–panning Wayland because it isn’t a drop-in replacement for X11. And he’s in the news again for a new Github repo with the aspiration of creating protocols for functionality not currently available to Wayland-native apps that are intentionally missing in Wayland’s standardized protocols–which won’t work because lacking standardization means they won’t become a part of the platform that app developers can reliably target.
There’s a bit of chuckling and jeering over this in developer circles, but to regular people, the whole “Wayland breaks everything” charge might ring true, or at least seem like it contains a kernel of truth. Because from a certain perspective, he’s right: Wayland really does break everything that directly uses X11 functionality!
It’s just that this is the wrong perspective.
Look, if I said, “Linux breaks Photoshop; you should keep using Windows!” I know how you’d respond, right? You’d say “Wait a minute, the problem is that Photoshop doesn’t support Linux!” And you’d be right. It’s a subtle but important difference that puts the responsibility in the right place. Because there’s nothing Linux can do to ‘un-break’ Photoshop; Adobe needs to port their software, and they simply haven’t done so yet.
And it’s much the same with X11 and Wayland. Wayland wasn’t designed to be a drop-in replacement for X11 any more than Linux was designed to replace Windows. Expectations need to be adjusted to reflect the fact that some changes might be required when transitioning from one to the other.
Now, even though Wayland wasn’t designed to be a drop-in replacement for X11, it was certainly intended to eventually replace it. But this implies that it was intended from the start to do less than X11, and and that would be correct.
X11 was a bad platform
In ye olden days, X11 was a whole development platform. Your app that targeted X11 could use X11 to draw its UI with a built-in widget toolkit; print documents with an included print server; record the screen; set global keyboard shortcuts; and so on. This is all way before my time, but I get the sense that X11 was either originally envisioned to be a development platform for app developers, or else quickly morphed into one during its early days.
It didn’t work out. The built-in UI toolkit looked horrendous, even for the standards of the time. Apps that requested the same resources could stomp on one another and break each others’ functionality in ways that were impossible to fix short of uninstalling one of the apps. Features like printing withered because a window manager was really the wrong place to put that functionality and its later maintainers lacked the needed expertise or interest to maintain it. And so on.
UI toolkits like Qt and GTK quickly rose up to take over most of this sort of app platform middleware in a way that worked much better for users and was easier to target for app developers. We’re talking about the mid 90s here; it was a long time ago.
(Of course this is slightly unfair; lacking a print server isn’t what people complain about being missing from Wayland. It’s more like things like apps able to set custom window icons and move their own windows. These are the really hard cases; they aren’t present on Wayland because they were commonly abused by apps on X11 to cause unsolvable problems. It’s not an easy thing and there are trade-offs involved in bringing them to Wayland.)
Linux isn’t a platform
Anyway, the rise of UI toolkits necessarily fragmented the app landscape. Instead of developing for one target (X11), a FOSS app developer now developed for Qt, or GTK, or whatever, so we ended up with a lot of “KDE apps” and “GNOME apps.” Yes, these apps still probably worked elsewhere, but it was obvious what platform and toolkit they been developed to work best in. They might look and feel weird when run elsewhere, or certain features might not work well or at all.
And that’s where we remain today. Absolutely nobody writes an “X11 app”; their app may use functionality in X11 for something that there’s no better way to do, but the app will use Qt, GTK, KDE Frameworks, or whatever for 99.9% of its functionality.
It brings us to a potentially thorny topic: Linux isn’t really a platform either, any more than X11 succeeded at being one. Almost nobody writes a “Linux app”; making raw Linux kernel system calls is generally unnecessary because whatever UI toolkit you’re using wraps this functionality and abstracts it to all the different platforms that the toolkit supports. The toolkit ensures that it just happens to work on Linux too.
The real platform
So is all hope lost for cross-desktop interoperability? No. In fact prospects are better than they have been in a long time! Because today there is in fact an emerging platform; something that abstracts away even the app toolkits if you want to roll that way. I’m talking about Portals, PipeWire, and Wayland protocols.
Probonopd pans these as bolt-ons that you shouldn’t have to have running on your system, but I think this isn’t realistic. The model of the monolithic window server that offers all functionality failed decades ago. In its place, we have libraries and APIs that every FOSS developers can reasonably expect a modern system to be running.
The portal system offers a standardized way to present platform-native open or save dialogs, send notifications, open documents in other apps, print documents, take screenshots, record the screen, handle drag-and-drop, see if the user’s active theme is light or dark, and much more. The portal system uses PipeWire under the hood for a lot of this stuff, so you can expect that to be installed as well. And you can also expect most Wayland compositors–most notably the two most important ones KWin and Mutter–to support pretty much all publicly standardized Wayland protocols.
I think this is the platform: Portals-and-Wayland-and-PipeWire. Clearly we need to come up with a better name. 🙂 Maybe PW2. But if your app targets these, it will run on pretty much every modern Linux system. And the big two FOSS toolkits of Qt and GTK both have cutting-edge support for all of it. So use whatever UI toolkit you like.
Why now?
We’re hearing more about this recently because the transition is picking up steam. X11’s maintainers have announced an end to its maintenance. Plasma is going Wayland by default, following GNOME. Fedora is dropping X11 support entirely. We’re in the part of the transition where people who haven’t thought about it at all are starting to do so and realizing that 100% of the pieces needed for their specific use cases aren’t in place yet. This is good! Them being heard is how stuff happens. I wish it had happened sooner, but we are where we are, and there are a lot of recent proposals and work around things like remote control, color management, drawing tablet support, and window positioning. There will probably be an awkward period before all of these pieces are in place for all of the people. And for the those who really do suffer from showstopping omissions, I say keep using X11 until it’s resolved. No one’s stopping you (well, except for Fedora, so if this is you, don’t use Fedora. 🙂 The cutting edge should be fun! If it isn’t, try something else).
Wrapping up
In this context, “breaking everything” is another perhaps less accurate way of saying “not everything is fully ported yet”. This porting is necessary because Wayland is designed to target a future that doesn’t include 100% drop-in compatibility with everything we did in the past, because it turns out that a lot of those things don’t make sense anymore. For the ones that do, a compatibility layer (XWayland) is already provided, and anything needing deeper system integration generally has a path forward (Portals and Wayland protocols and PipeWire) or is being actively worked on. It’s all happening!
Adventures in Linux and KDE 
