At this point you’ve heard a lot about Plasma 6, and each of my weekly “This week in KDE” brings news of a few new features, UI changes, or bugfixes that are only in Plasma 6. But how do we get there, and how long will it take? So today I’d like to talk about the process and schedule a bit. Let’s start with an outline of the required steps to get there, in sequential order:
- Make it compile
- Make it livable
- Clean up the code
- Implement planned features and changes
- QA it and fix the bugs
Are we there yet?
My sense right now is that we’re in the middle of steps 3 and 4. Basically everything in Plasma compiles with Qt 6, and at this point Plasma 6 is fairly livable. To give you a sense of how livable, it’s good enough that over the past 2 months, I’ve gone on three KDE-related trips from the USA to Europe, with my only computer running Plasma 6 in “current git master” state, with work-in-progress merge requests applied! Its stability has been good enough that this has caused me no apprehension, and indeed, it’s been totally fine on each trip.
So seriously, if you’re a KDE developer or an adventurous user, start living on Plasma 6! Jump right in, the water’s fine. 🙂
If we’re not there yet, where are we?
Right now the most active work is in step 3 code maintenance. Tasks already completed include an overhaul of the API for Plasma widgets, which affects basically everything. This project makes it easier to write Plasma 6 widgets that function properly using standard components, and allow us to add future capabilities to the basic widget structure in a way that all widgets will get for free.
Less code duplication
Next up, we’re porting most of the PlasmaCore and PlasmaExtras units, color theme components, and user interface elements to their Kirigami counterparts. This is important since it lets us remove a ton of code that’s currently duplicated across Plasma and Kirigami with only minimal differences. We’ll be able to use the Kirigami things everywhere and work towards the goal of having only one set of QtQuick-based UI components. This is a big deal! More code re-use means more eyes on less code, resulting in better quality and faster development.
Right now the only Kirigami UI component that’s a drop-in replacement is Kirigami.Heading, which can replace PlasmaExtras.Heading on a one-for-one-basis. Then we can delete PlasmaExtras.Heading entirely!
After that, we’ll start on the second part, which consists of making it possible for Plasma to use more complex Kirigami components that internally draw desktop-themed UI elements like buttons and text fields. We’ll basically make them smart enough to substitute the relevant Plasma-themed versions under the hood when they detect they’re running in Plasma. This will let us port PlaceholderMessage, ActionTextField, SearchField, and PasswordField to their Kirigami equivalents, and delete the PlasmaExtras versions.
KSvg
Simultaneously, we’re also porting away from PlasmaCore’s SVG-handling capabilities and instead using a new SVG-handling library that’s named–get this–“KSvg.” It’s basically the PlasmaCore stuff, but extracted into its own library. This was done to make Plasma 5’s powerful SVG handling capabilities available to software outside of Plasma, such as KDE and 3rd-party apps.
Actions in headers
UX changes are landing as well. One effort I haven’t blogged about yet is a change to how we expose page-specific actions on System Settings pages–known internally KCMs, or “KDE Control Modules”. Previously, it was up to each KCM to write its own custom UI for everything. If it wanted some buttons, the convention was to create some and put them at the bottom of the page. But KCMs are embedded within System Settings, which draws its own button bar below the page. The result was a double stack of button rows in many KCMs, with a very heavyweight appearance.
In Plasma 6, we’ve written the capability for KCMs to declare their actions in a more, well, declarative way. Instead of drawing the buttons themselves, they broadcast their actions and those actions turn into UI elements automatically in the right place. Kirigami apps have had this feature for years, and now through more internal use of Kirigami, the capability is coming to KCMs as well! We’re currently using the feature to move footer actions to into headers, which saves space and results in a more lightweight look. Here’s a preview:
Because we’re KDE, all of this work is happening in a fairly anarchic, nonlinear fashion. We don’t have change control meetings or prevent people from working on later-stage tasks. This takes skill in communication and git rebase to avoid stepping on people’s toes. 🙂 But it is happening, in its own messy and beautiful way.
Why does it take so long to do all this code maintenance stuff?
Porting is easy and fast if you don’t do any QA. But if you do, you’ll discover a million tiny papercuts caused by subtle differences in the new thing you’re porting to. Testing changes, iterating on code, and adapting to other changes made to the repos all take time. We’re doing it slowly because we want to do it right. QA is critical to shipping a good product, especially when there are many far-reaching changes.
C’mon, where’s the schedule?
I’m afraid there is still no formal schedule with dates on it. But you can use the above step-by-step process as a rough barometer of completeness.
I expect most of the large-scale code maintenance work to be done by the beginning of August, at which point the focus will shift to new features and UX changes. It’s impossible to give an accurate estimate for how long that part will take, but as an extremely rough guess, I’d say 2 months at a minimum.
The QA and bugfixing work will be happening simultaneously, since that latter work is what gates the release; ultimately having a polished release with few new features is more important than the reverse (though both is even more desirable, of course). I want at least 2 months of QA and bugfixing time for Plasma 6, with multiple beta releases.
This would take us into the middle of November. This is most likely the earliest timeframe for a Plasma release, and it would require everything to go right, including a huge burst of contributor activity around QA and bugfixing. The likelier scenario is a release sometime between this December and March of next year.
Please note that this is a wild guesstimate! It is not an official schedule. Do not interpret or represent it as such. Do not say “hey everyone Nate told us Plasma 6 will be out around the end of the year.” These are my personal rough guesses!
How to help
If you’d like to help make these guesses become more concrete, the time to help is now. We need it! Test Plasma 6 and submit bug reports for things that worked in Plasma 5 but broke in 6. Test open Plasma 6 merge requests and find any regressions in them before they merge. Help port older Plasma stuff to Kirigami and KSvg. Work on approved Plasma 6 changes. Fix open bugs. Help make it happen! And if you find yourself with more money than you have time and skill, consider donating to KDE e.V. so we can expand our sponsorship of impactful development work. It really helps!
Adventures in Linux and KDE 