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!