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!