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:

• Starting number of bugs: 92
• Current number of bugs: 32
• 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!

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 PW². 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!

Wayland. It comes up a lot: “Bug X fixed in the Plasma Wayland session.” “The Plasma Wayland session has now gained support for feature Y.” And it’s in the news quite a bit lately with the announcement that Fedora KDE is proposing to drop the Plasma X11 session for version 40 and only ship the Plasma Wayland session. I’ve read a lot of nervousness and fear about it lately.

So today, let’s talk about it!

What is Wayland?

Wayland is a set of protocols that govern how a compositor draws stuff on the screen, and how apps interact with the compositor’s drawing-stuff-on-the-screen infrastructure. It’s similar to the HTTP and SMTP protocols that govern how web browsers and email clients send and receive web pages and data.

Wayland also includes an implementation of those protocols in a set of extremely lightweight libraries called libwayland-client and libwayland-server that offer stable and versioned APIs. Apps and compositors such as KDE’s KWin and GNOME’s Mutter use those APIs to do stuff.

Why does Wayland exist?

In a nutshell, because X11–the thing it’s replacing–is dead.

X11 has been in maintenance mode for years, and recently has gotten no real development at all other than changes to the XWayland compatibility system that allows X11 apps to use a Wayland compositor. Having something as central as the window server being unmaintained is a major issue, as it means no bug fixes, no security patches, and no new features to let it keep up with a changing world.

Why did X die?

The fundamental X11 development model was to have a heavyweight window server–called Xorg–which would handle everything, and everyone would use it. Well, in theory there could be others, and at various points in time there were, but in practice writing a new one that isn’t a fork of an old one is nearly impossible. Everyone strongly preferred to standardize on a single X server and migrated in unison from one to another when a better fork became available, because it was convenient. And it was convenient because because it centralized limited development resources, and when a feature was added to the X server, everyone gained access to it automatically.

But there was a drawback: because everyone was using Xorg, any feature added to support any use case could break everything else that everyone else used, and this happened frequently. Bug fixes frequently regressed obscure functionality that others were using.

In essence, Xorg became too large, too complicated, and too fragile to touch without risking breaking the entire Linux ecosystem. It’s stable today because it’s been essentially frozen for years. But that stability has come hand-in-hand with stagnation. As we all know in the tech world, projects that can’t adapt die. Projects that depend on them then die as well.

How is Wayland any better?

Wayland was conceived of by X developers who wanted to avoid repeating their own mistakes. In addition to a lot of technical differences, by being a minimal set of protocols and two extremely thin client and server libraries, all the heavy lifting was delegated to individual compositors, which became the window servers of their environments. A new feature added to one would not destabilize any other compositors. Compositors were also free to implement new features via private protocols outside of the standard ones that apps only targeting that compositor could use.

Wait, that sounds like it sucks

Wayland has not been without its problems, it’s true. Because it was invented by shell-shocked X developers, in my opinion it went too far in the other direction. Wayland’s minimal core protocols are lacking most of the features that non-trivial apps and desktops actually need to work–such as screen locking, screen sharing, cross-app window activation, non-integer scaling, and so on. Compositors all needed to come up with ways to do these things themselves. And that need for each compositor to implement everything itself fragments development efforts and disadvantages small teams without the expertise of heavy-hitting graphics developers. These are real problems and we shouldn’t sweep them under the rug.

Yes, but there are solutions

Over time the minimal core protocols have been extended to cover what’s needed for a Linux desktop and sophisticated apps to work. Much of this work is very recent, driven by KDE, and funded by Blue Systems and Valve Software. So most complaints you read about Wayland missing this or that (such as fractional scaling, or screen sharing, or global shortcuts) from over a year or two ago are likely to be wrong today.

In addition, the problem of fragmentation of effort is being solved by wlroots, a library of Wayland implementations that you can use to build a Wayland compositor. We don’t use it in KDE’s KWin compositor because we already did most of that work ourselves before wlroots existed, but it’s a big benefit to anyone writing a new compositor from scratch today. And there’s a chance we might port KWin to use wlroots in the future.

Why is the adoption taking so long?

The fact that Wayland’s minimal core protocol made it unable to fully replace the thing it aimed to replace was a bad architectural design decision on the part of its authors that crippled the prospect of its rapid adoption when it was released in 2008. We didn’t see the same problem with other newer projects like Systemd and PipeWire which were adopted much faster.

And unfortunately, shepherding new protocols through the approval process to fix this problem is a grueling political exercise. It demands empathy and compromise with people from other projects who approach the problem you’re trying to solve from a fundamentally different perspective. Someone may disagree that the problem is even worth solving. Bikeshedding derails the discussion and everyone gets demoralized and stops working on it. For a long time, the urgency of pushing through it was low because X wasn’t dead yet.

So it took over a 15 years and resulted in Wayland’s dirty laundry being aired in public for that whole time. And that sucks. But… we’re there now. Standard protocols now exist for just about everything anyone needs. The few remaining obvious omissions (like screen color calibration) are being actively worked on as a matter of priority.

“Are we there yet?”

Plasma and KDE apps work great on Wayland, especially in the upcoming Plasma 6 release. Like I said, there are still a few omissions, but those holes are being plugged very quickly these days.

Most 3rd-party apps that aren’t Wayland-native also work fine via the XWayland compatibility layer. But there are some that don’t, because they integrate very deeply into some part of the system in a way that requires X11 support. These need to be ported to use new Wayland APIs.

A lot of app developers became accustomed to tuning out Wayland news while it was still a toy, and didn’t do the porting work. Well, it’s not a toy anymore, and now many are now feeling blindsided by the sudden urgency to port their apps to use Wayland. That’s understandable. But this time it’s for real, and the time to port is now. For any protocols that still aren’t good enough and need revision, app developers’ input is needed to revise them or even propose new ones. This process takes a long time, so better to start sooner rather than later. But it’s not just gonna go away.

Which brings us to Fedora KDE

Fedora has always been a “leading edge” distro that pushes forward the technical state of the art on Linux by adopting new technology once it’s mostly ready, thus causing it rapidly improve in a way that it otherwise would not have. Fedora was the first distro to adopt Systemd, PulseAudio, and PipeWire. It was the first to use the Plasma Wayland session by default. And now Fedora KDE wants to be the first to drop the Plasma X11 session entirely and make everyone use the Plasma Wayland session.

It should be clear that Fedora’s target audience consists of people who are excited about change. If this is you, all of these projects should seem exciting and cool! If not… then Fedora isn’t for you. And that’s fine. The Linux world has approximately five hundred bajillion distros. What’s that you say? Only about 20 of them are any good? Well, fair enough, but even if that pulled-out-of-someone’s-butt number is accurate, there are still 19 distros that aren’t Fedora! Reinstalling your OS is unpleasant, but it’s important to choose the right one that suits your needs and preferences. Choice comes with the responsibility of choosing wisely.

Maybe you’re afraid that Fedora is a “canary in the coalmine” that shows the way everything is going to go. And you wouldn’t be wrong about that, but transitions still take time. Distros that intentionally ship old software like Ubuntu LTS or Debian Stable will let you keep using X11 for years and years. Arch will probably keep shipping X11 for a while too. You have options. By the time Ubuntu LTS removes X11 too, everything will be fully ready.

Putting it all together

Wayland is a replacement for X11, which is dead. Despite a rocky development process, it’s ready enough for Plasma and KDE apps that Fedora KDE is pushing it pretty hard. Many 3rd-party apps are already Wayland-native, but many are not, and they need to put in the work to port to Wayland. If anything they need is still missing, they need to step up to be part of the process of adding it. This process is happening, and isn’t going to stop happening. We need to work together to make it happen faster and more smoothly.

A month has passed since the last Plasma 6 status update, so it’s time for another one!

First, what you’ve all been waiting for: a release date! We’ve decided that Plasma 6 will be released in early February of 2024. We don’t have a specific day targeted yet, but it’ll be in that timeframe. I’m feeling quite confident that the release will be in excellent shape by then! It’s already in good shape right now. 5 months should provide enough of a runway for a solid final release.

What’s done

Over the last month, a few remaining porting tasks were completed:

• Replace PlasmaCore.SortFilterModel with KItemModels.KSortFilterProxyModel. Less code duplication, yay!
• Replace Kirigami.Avatar with KirigamiAddons.Avatar and KirigamiAddons.AvatarButton, which are easier to use and better-behaved.
• Introduce an opt-in dedicated sidebar column UX for System Settings KCMs, and port various bespoke stuff to use it.
• DataEngines have been made into thin wrappers around other functionality and moved into a new package called Plasma5Support, so porting away from them isn’t so urgent anymore and won’t block the release.

This work was done by Marco Martin, Arjen Hiemstra, Carl Schwan, Nicolas Fella, and me: Nate Graham. All this porting work is leveling off as the major work has now been completed, making room for features and bugfixes. This means we are solidly in stage 4 of the roadmap (features and planned changes) and nibbling on stage 5 (QA and convergence).

In the feature department, major work included:

• Custom ordering for KRunner search results
• Printers KCM rewritten in QML
• Double-click by default
• Tap-to-click by default
• Icons throughout Plasma itself now exclusively come from the systemwide icon theme
• Support for automatic bug reporting in DrKonqi and improved reporting flow in general
• Autostart KCM shows details about entries
• Distros can now customize the first page in Welcome Center

This work was done by Alexander Lohnau, Mike Noe, Harald Sitter, Nicolas Fella, Thenujan Sandramohan, Xaver Hugl, and me, Nate Graham.

In terms of bugs, it’s been an all-hands-on-deck affair, with everyone helping out. As a result our list of open Plasma 6 issues is down to 75 today, after having risen three weeks ago to an all-time high of 87. The number has been falling since then, which is a great sign–bugginess has peaked and we’re starting to converge! And not all of these are major, high profile issues, either; as of this writing, there are only 15 of those. These are the true showstoppers that must be fixed before we can release Plasma 6. As for the rest, we’ll be trying our best to get as many of those done too to ensure that quality on release day is as high as possible!

What’s next

There are a lot of items remaining in the “Work that’s been decided on but not implemented yet” section on the Plasma 6 wiki page–both started but not yet finished, and also not yet started. It’s time to get cracking on that stuff! If you want your features to be included in Plasma 6.0, we have about 2 months to do it before the soft feature freeze.

Beyond that, it will be a matter of bugfixing, bugfixing, and more bugfixing!

How to Help

Basically the same as last time: if you’re a developer, live on Plasma 6, work on your features, and fix bugs! If you’re a user, test out Plasma 6 and report issues! And if this makes you feel excited in your nether regions, reach for your wallet instead and make a donation to KDE e.V. so we can continue to fund that which needs to be funded!

Today I want to discuss in detail our plans for icon theming in Plasma 6. It will be rather technical, but may be of interest if you’re a user, developer, or theme author who wants to know what (if anything) you’ll have to do differently for Plasma 6.

---

Let’s start by briefly reviewing the way FreeDesktop-compatible icon themes work. Icons in icon themes are named with standardized names, like edit-copy. A list of standard names can be found here. When an app wants the icon for a “Copy” action, it uses the API of its toolkit to ask for a themed icon named edit-copy. In Qt, you use QIcon::fromTheme(). If an icon isn’t found by its name, the implementation is required to chop off the last word and try again. So if an app asks for edit-copy-path and an icon with that name isn’t found in the icon theme, it will look for edit-copy and return that instead. Icons can also come in multiple sizes, so that each icon can be optimized for being displayed at different sizes. There’s more to it than that, but it’s enough for now.

Over time, icon themes started doing something interesting: they changed the visual styling between sizes! For example in many icon themes, the symbolic monochrome style is used for icons’ 16px and 22/24px versions, and a full-color style is used for the 32px and larger versions. Breeze is one such icon theme. For example:

Now we have a problem. What if an app developer wants to display an icon at 32px size, and they want it to be symbolic even if if the theme has both symbolic and full-color versions of the same icon? There is actually no way of expressing this preference.

This was a common issue with icons in a Plasma Panel, which has a variable thickness. So when you were using the Breeze icon theme, any Panel widgets that asked for an icon present in the icon theme might become colorful if the panel was thicker than 32px (excluding padding). Some icons also only had full-color versions, and others only had symbolic versions, so the result was a jumble of visual styles on your Plasma Panel.

The old solution

Because this was primarily a problem in Plasma, in the past we solved it by shipping icons inside the Plasma style that overrode the icons in the system-wide icon theme. The Plasma-specific icons could be always symbolic at all sizes. Unfortunately there were many drawbacks:

• The style of icons in the Plasma style might be different from the style of icons you chose for your System-wide icon theme, making unified theming impossible unless you also applied a matching icon theme made by the author of the Plasma theme.
• Plasma themes often had only a few icons in them, meaning that most icons in Plasma respected your system icon theme, but some didn’t, and which ones didn’t was dependent on what Plasma theme you were using and how many icons it included. In practice it felt totally random.
• Even when developers offered matching icon and Plasma themes, it was an easily-forgotten chore to remember to update the same icons in both places, causing them to get out of sync.
• This solution required the use of different icon loading code between apps and Plasma, with subtly different behaviors, features, bugs, and performance characteristics–not to mention twice the maintenance.
• Apps encounter the same issue, and this Plasma-specific solution doesn’t work for them.

For these reasons, we wanted to move away from this system in Plasma 6.

The new solution

For Plasma 6, icons in the Plasma theme will no longer be used even if they’re present. All icons in Plasma now come from the system-wide icon theme.

So how do we solve the above issue? Well, remember how the system falls back to an icon with a simpler name when it’s asked for an icon with a more complex name that isn’t found? The GNOME folks have used this feature to do something clever: they appended the -symbolic suffix to the end of their symbolic icons. Then when an app asks for, say, media-optical-audio-symbolic, it gets the symbolic version of the icon even if it’s being displayed at a large size such that otherwise it would get the full-color one.

For Plasma 6 we have adopted this convention as well for our Breeze icon theme. This isn’t an official part of the icon theme spec, but now that both GNOME and KDE do it, hopefully it shouldn’t be that hard to amend the spec to include it.

What it means for users

In Plasma 6, all icons in both your apps and Plasma will come from your icon theme. If you want your icons to look different, use a different icon theme.

What it means for app and Plasma developers

Anywhere in your app where you want the user to see a symbolic icon if the icon theme has one, append -symbolic to the end of the name of the icon that your app asks for. So yes, you’ll end up with a lot of git diffs like this:

Due to the name fallback behavior, this is a fully backwards-compatible and harmless change. So it’s not urgent to do this. But if you don’t, sometimes your users will see a full-color icon even though a symbolic one that you might prefer they see is available. So I encourage it!

What it means for icon theme authors

If your icon theme only has symbolic icons, or only has full-color icons, you don’t need to do anything.

If your theme has both symbolic icons and full-color icons, but there aren’t any icons that use different styles at different sizes, you don’t need to do anything. However do consider adding symbolic versions of your full-color icons that might get used on buttons, menu items, system tray items, and other places where people commonly expect to see symbolic icons. The filenames of the symbolic versions should end with the -symbolic suffix.

If your icon theme has any icons with symbolic versions at some sizes, and full-color versions at other sizes, you should create symlinks that end with the -symbolic suffix and point to the symbolic versions. Here’s an example of what we do in Breeze icons:

What it means for Plasma style authors

Don’t include icons in your Plasma 6 styles; they won’t be used. If you want your Plasma style to be accompanied by a distinctive matching icon style, bundle it in a Global Theme that also specifies the icon theme matching its style.

In conclusion

Nah, no conclusion needed. That’s all for today, folks!

About 6 weeks ago, I posted a tentative roadmap for Plasma 6. I wanted to give everyone an update on how things have gone since then!

So where are we? I previously explained that we were somewhere in between “clean up the code” and “Implement planned features and changes”–stages 3 and 4. I predicted that stage 3 code cleanup would mostly be done by early August.

What’s done

I’m happy to report that my prediction appears to have been pretty accurate! As of today, almost all of the planned Plasma 6 code porting tasks have been completed. Only one major one remains: porting everything away from DataEngines. But everything else is done, including the following projects:

• Port all usages of Plasma SVG elements to KSvg (link)
• Port everything to use Kirigami colors and Units (link)
• Port PlasmaExtras.Heading to Kirigami.Heading (link)
• Port away from direct KActionCollection usage (link)
• Improve and modernize wallpaper API (link)
• Improve and modernize Plasmoid component API (link)
• Improve and modernize Plasmoid actions API (link)
• Port PlasmaCore.IconItem to Kirigami.Icon (link)
• Port to declarative header actions in KCMs (KCM is short for “KDE Control Module” and it’s internal jargon for a page in System Settings) (link)

These projects have involved many people, including: Marco Martin, me: Nate Graham, Laurent Montel, Carl Schwan, Mike Noe, Jorge Barroso Barea, Ivan Tkachenko, Joshua Goins, Kai Uwe Broulik, and Oliver Beard.

Now before we continue, let me mention that there’s much more porting work also going on in the background in Frameworks 6 which is technically independent of Plasma 6. This important work has been done by people like Volker Krause, Nicolas Fella, Friedrich Kossebau, and many others! Thanks for this work as well, guys!

Most of the Plasma porting projects should result in exactly zero user-facing changes, and I’ve done a lot of QA work over the past two months to make sure that’s the case. But the last two projects are exceptions; in addition to being porting and code cleanup projects, they do result in some intentional user-facing changes. Let’s go over them:

Using Kirigami.Icon everywhere is a part of the project to deprecate icons that live in the Plasma style, and always use icons from the (configurable) systemwide icon theme instead. That’s tracked at https://invent.kde.org/plasma/plasma-desktop/-/issues/82 and it’s now been completed! This makes it easy to achieve a consistent icon style across both Plasma and apps. Here’s how my system looks today with the style ze Plasma and the popular Papirus icon theme applied:

Fairly complete icon themes already look great! Others will need to add some new icons that are only displayed by Plasma, which was not necessary in Plasma 5. Icon theme creators take note! And I’ll write a separate post about this later.

Porting KCMs to use header actions also results in a user-facing changes. Now System Settings KCMs have largely dropped their double-height footers by moving some of the footer actions to their headers. The result looks great:

Not too shabby, eh?

What’s next

As I mentioned, we still need to port all the widgets away from DataEngines. That’s ongoing. And there are some more lower-priority porting projects that we’ll be working on over time, such as removing custom CompactRepresentation code from widgets in favor of using the standard one and using the standard QML KCM components in Plasma widgets’ config windows. Those are lower priority though, and can be done at any time, including after Plasma 6 is released.

Beyond that, it’s time to move fully into stages 4 and 5: implementing planned features and polishing everything up in preparation for a release. In addition to the features relating to icons and KCMs that I mentioned earlier, a bunch more planned changes are mentioned on the Plasma 6 wiki page. Folks will be starting work on those soon. These planned changes are of course in addition to the random and awesome unplanned changes submitted by volunteers not working in close coordination with the Plasma team. For example the Autostart KCM is undergoing heavy changes right now as the result of some excellent volunteer contributions. So expect Plasma 6 to have a lot of amazing things in it!

How to help

If you’re a developer

Help port widgets away from DataEngines so we can close the lid on major porting work.

Also, start submitting merge requests for your major feature work. If you want it to ship with Plasma 6.0, the time to do so is now! We have probably a 2-3 month window of time remaining before we start branching for betas and any new features have to be deferred until Plasma 6.1.

And finally, since you’re already living on Plasma 6 git master (no doubt! 🙂 ), go fix some more of these bugs you encounter on a daily basis! You know, the ones that are annoying you but you already found a workaround? Delete your workaround, then fix it for everyone! Can’t find any bugs? Fix some of these!

If you’re an excited user

Test out Plasma 6 in a real environment! Use it. Test it. Break it. Find all the bugs. And then report them on https://bugs.kde.org! We want the number of open bug reports to go up for a while, as this represents people reporting issues that have been newly found, or weren’t previously tracked with Bugzilla tickets. We need that! Everything must be tracked!

If you’ve got money to spare

KDE is run by people volunteering their time to work on it or sponsored to do so by their employers, but now KDE e.V. is one such employer too! And [puts on board member hat] we want to make sure we have the financial leeway to remain one. The majority of KDE e.V.’s funding comes from small individual donations (here are the ones from PayPal, for example), and you can be a part of keeping it that way! Every little bit helps us to continue to pay our server bills, host free-to-attend conferences and sprints and even pay for people’s travel costs, employ folks to develop, package, and promote the software, and so on. If you can make a donation, we’d really appreciate it!

Icons on the desktop!

The minimize button!

Visible Panels and docks!

Just kidding, don’t have a heart attack. 🙂 Well actually there are some things… just not those! The full list can be found at https://community.kde.org/Plasma/Plasma_6#Removals, and it’s public; we’re not hiding anything! Today I wanted today provide a bit of context and explain the why, since it may not be obvious how it makes sense to remove things. So let’s go through the list:

KHotkeys

This was an earlier implementation of a global shortcut system that eventually grew niche though much-loved features such as mouse gestures. Unfortunately those features did not work on Wayland, many other features were critically buggy, the configuration and data storage formats were non-standard and fragile, and the code in general was in an advanced state of bit-rotting after having been abandoned for many years. We already have global shortcuts working using the newer KGlobalAccel system, and we’d already hidden the KHotkeys config UI from System Settings on Wayland in Plasma 5. So we made the decision to double down on KGlobalAccel and just finally delete KHotkeys once and for all for Plasma 6, rather than awkwardly ship two parallel global shortcut systems, which was always very odd and really not justifiable at all. Mouse gestures can eventually be added to KGlobalAccel if someone takes an interest in doing so. No one’s opposed to it!

The “Windowed Widgets” KRunner runner

In Plasma 5, various widgets appear in search results, and activating them will make the widget appear on the desktop in windowed form. This was one of those “Becuase we can!” features that showed off some cool technology, but feedback indicated that it was confusing some users into believing that widgets were actually small apps, and they were using widgets as apps instead of using KDE’s more powerful apps, or even finding an app that met their needs better. Widgets are deliberately very small and limited and we didn’t want people to get the wrong impression about KDE apps. So we decided to remove the feature in Plasma 6.

The Wayland Force Font DPI and global “Icon size” settings

It’s been my experience that in general, users are very confused about how to adapt the UI to a particular screen’s resolution, or change the size of user interface elements on their systems to suit their preferences. This makes sense because there are no fewer than seven ways to do it, each with its own subtle pitfalls and drawbacks:

1. Per-screen resolution setting in System Settings > Display and Monitor
2. Global or per-screen scaling slider in System Settings > Display and Monitor
3. Force Font DPI spinbox in System Settings > Appearance > Fonts
4. Adjustable font size in System Settings > Appearance > Fonts (because lots–but not all–UI controls resize themselves in proportion to the font size)
5. Adjustable icon sizes for many icons in many KDE apps in System Settings > Appearance > Icons
6. Adjustable icon sizes in many individual KDE apps (e.g. Dolphin and Gwenview main view, Places Panel sidebar, etc)
7. Whole-app scaling systems in various apps (e.g. scaling slider in Telegram, whole UI responsive to Ctrl+plus and Ctrl+minus in electron apps)

This is a major problem because such a DIY experience ensures that users will find and use random scaling settings that don’t interact well, introduce weird visual issues into their systems that cause other issues, look for and implement workarounds that can have even more bad effects, and so on. It’s just a mess. Speaking as KDE’s most prolific bug triager, this is something I see over and over and over again; I even have a canned response for it. It’s a real problem.

So for Plasma 6, we’re removing methods #3 (On Wayland) and #5 (everywhere) to simplify this situation and help people use supported and better-functioning ways to scale their systems.

A bunch of low-quality Task Switchers

While working on the now-completed project to ship with a better default Alt+Tab Task Switcher, we found that the “Grid”, “Informative”, “Small Icons”, “Text Only”, and “Thumbnails” Task Switchers were largely worse versions of other Task Switchers. So for Plasma 6, we have removed them, to steer people towards better options. Anyone who really loved any of these can feel free to put them up on https://store.kde.org.

The Air Plasma style

This old Plasma style lived in the plasma-framework repo for a long time, but was abandoned and bit-rotting. It also didn’t really make sense to ship a non-default theme this way, when we already have the Get New [thing] system to let people find and download their own cool new stuff from https://store.kde.org. So we made the decision to remove it. As with the Task Switchers, anyone who loved it is encouraged to maintain it and stick it on https://store.kde.org.

Per-Activity power settings

These very niche and infrequently-used settings were mostly broken, but the infrastructure to support them increased the code complexity of a fragile part of the system. In the interest of improving Plasma 6’s stability and removing known-broken settings, we have removed them rather than putting in the substantial effort needed to fix them.

System Settings Icons view

This view has been superseded by the Sidebar view and abandoned code-wise for years. It’s missed important features such as the “Highlight changed settings” feature that the Sidebar view got years ago. Nevertheless, it was kept around because for a time it offered better keyboard navigability compared to Sidebar view. However following an accessibility push, this is no longer the case, so it doesn’t offer any real advantages anymore and we plan to delete it for Plasma 6. Offering multiple visualization options for something like a Settings app was always kind of weird anyway.

Icons in Plasma Styles

In Plasma 5, the icons shown in various parts of Plasma widgets (but not apps) can come from one of two places: the active icon theme, or the active Plasma style. How do you the user know which icons come from which place? You can’t, not easily. What can you do if you apply a Plasma style and it includes weird icons that make your Plasma widgets look visually inconsistent with the rest of your system–but only partially? Nothing!

Needless to say, this is not ideal.

The original purpose of the feature was to allow Plasma styles to ship monochrome System Tray icons even when the rest of the system is using a colorful icon theme, which even at the time was a questionable goal and amounted to the system visually fighting with itself and its users’ icon theme choices. Later it gradually increased in scope so that lots of other random icons were added to Plasma styles and overrode icon theme icons–but never all of them, only some of them. Some Plasma styles included very comprehensive sets of icons, others included none, and some included a random incomplete assortment of them. All in all it was very strange and very random-seeming.

For Plasma 6, we’re removing this questionable feature, and icons in Plasma widgets will always come from the systemwide icon theme. Much simpler, much more user-comprehensible, much better visual results 99% of the time.

If you’re a theme creator who’s worried about this change, just put the icons that are currently in your Plasma style into that style’s companion icon theme instead.

Unsplash Picture of the Day

This one is quite sad, as no one wanted to remove it. Alas, we had to because Unsplash changed their terms of service to preclude Plasma’s usage of it, as a way of fighting automated data scrapers for AI training models. With a heavy heart, we removed it. So the next time anyone asks you what AI can do for humanity, now you have a concrete answer: prevent Plasma 6 from shipping an Unsplash Picture of the Day wallpaper plugin. Thanks, AI!

The bottom line

You may have noticed some recurring themes: “doesn’t work well, not well integrated with anything else, unnecessarily duplicative, buggy, confusing, abandoned, obsolete.” And you wouldn’t be wrong! These removals have been carefully chosen because they don’t showcase the best of Plasma, and instead act as hidden minefields or make the system feel buggier. They represent common pain points for new users, sources of confusion and user support questions. Except for the Unsplash PotD thing; I’m still feeling salty about that. The robot apocalypse happened, and they took our pretty pictures!

“i don’t care, i still hate you for removing stuff”

I’m sorry you feel that way! But sometimes old things that don’t work very well have to be removed to make room and free up resources for new things that will work better. You’ll just have to trust us these are the right decisions—or at least, that they’ll be reverted if they turned out to be the wrong decisions. Or I guess you can go fork Plasma 5 and tell the internet how KDE is going down the tubes 🙂

…But hopefully not, because I think these removals really will improve the Plasma experience, and open up some space for making it even better in the future. Plasma has had a long, storied, and somewhat messy history, with ports to this toolkit and then that toolkit, with complexity and flexibility that didn’t end up used and caused bugs, with potentially cool features that didn’t pan out. By removing some of the old cruft from Plasma 6, we have an opportunity to build on the best of what we already had and make it even better, to finally converge the product from what has sometimes been a jumbled collection of tech-demo features into a cohesive whole. From DIY do DI-Whoa!