On the road to Plasma 6

Planning 5 Minutes

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:

  1. Make it compile
  2. Make it livable
  3. Clean up the code
  4. Implement planned features and changes
  5. 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!

Published by Nate

Published

45 thoughts on “On the road to Plasma 6”

  1. Hey everyone, Nate told us Plasma 6 will be out around the end of the year!

    Joking aside, what an awesome work by the KDE community!

    On a semi-related note: Is the Breeze theme ready for Qt 6 yet? I’m asking because based on the screenshots you’ve posted of Plasma 6, I’d “assume” it is.

    However, Flatpak apps that use the KDE 6.x runtime still use the Fusion theme, instead of Breeze (on my Plasma 5 desktop).

    Is this the expected behavior? Will I only be able to use Breeze + Qt 6 if my desktop is also running Plasma 6? 😦

    Thanks for the weekly updates!

    Like

    Reply

    1. > On a semi-related note: Is the Breeze theme ready for Qt 6 yet? I’m asking because based on the screenshots you’ve posted of Plasma 6, I’d “assume” it is.

      Yes. It works ~ on a Plasma 6 session, at least.

      Liked by 1 person

  3. Lets see: You screwed up KDE 4.14, forced fed us on KDE 5 which is a steaming pile of manure, that still lacks any videos, or manuals, and only became usable when KDE 5 reached Plasma 5.18.and then only after jumping through a large number of hoops, all to get the same point that required I check a box, say I want to use different backgrounds with separate widgets, and then I was on my way. Now I have to use the God awful “Activities” while standing on my head muttering incantations in Latin — backwards! — with my eyes closed. We were fed a whole pile of excuses WHY you could not recreate a simple interface that was perfected in KDE 4.14. We were told that 1) Qt5 was so much more difficult 2) then it was blamed on the developers not wanting to give users what the USERS WANTED 3) Followed by that the reason there were no videos or manuals was that it took time to create them 4) Excuses followed by excuses KDE 5 is still filled with bugs and usability problems. Rather than calling for a FEATURE FREEZE and FIXING KDE 5 and giving the USERS WHAT THEY WANT, not what DEVELOPERS WANT. Providing videos and manuals how to USE KDE 5.x.

    But here you jokers are once again talking about KDE Plasma 6 using Qt 6. So lets see if I got this right:

    1) The Developers are BORED — Poor Developers
    2) In order to perk up the Developers Interest You plan to introduce Plasma 6 using Qt6!!
    3) But converting to Qt6 that means you PLAN TO BURN EVERYTHING TO THE GROUND just like you did in switching from KDE 4 to KDE 5.
    4) Instead of giving USERS what THEY WANT, you are going to create “NEW and EXCITING “TOOLS” we can all get EXCITED about, but once again like KDE 5 / Plasma 5 you jackasses will REFUSE to a) Produce any useful videos on how to USE these new Features b) WRITE a DETAILED manual on how to use this crap.

    KDE USE to be USER FRIENDLY, now it is anything but.

    OK Since KDE Plasma 6 (!) is going to be a NEW project here are some suggestions for your Developers.

    1) Go back to KDE 4.14 and figure out how to create Individual Virtual Desktops that can each be set up with their own individual Wallpaper and each with its own individual set of widgets that is not replicated on all the other Virtual Desktops .

    2) Don’t force USERS to use “Activities” to do what could be done by checking a box that says “Different Widgets for Each Desktop”

    3) DON’T Force Feed Plasma 6 on Users. Some of us are still learning to use KDE 5. At the very LEAST allow the USER to CHOOSE between KDE Plasma 5 and KDE Plasma 6

    4) Start on Day 1 to WRITE the Manuals and produce PROFESSIONAL VIDEOS, not some “reviewer” who does some “Review” that covers everything, showing how to do something spending all of about 3 seconds on each task. These PROFESSIONAL Videos should show a Step-by-Step approach on HOW to accomplish something. I found only 1 such video in all of KDE Plasma 5.

    5) Don’t be the bunch of Jackasses you were with KDE 5. Make sure you you have a target date that includes a “NEW FEATURE FREEZE”. Then you can POLISH and DEBUG KDE Plasma 6, unlike the Steaming Pile of Manure that KDE Plasma 5 has turned out to be.

    6) KDE Plasma 5 was introduced on 15 July 2014 almost 9 years ago. The current version of KDE Plasma 5 5.27.5

    7) In contrast Plasma 4 was introduced on 11 January 2008, and 4.14 — the last release of KDE Plasma 4 was on 20 August 2014. It was highly POLISHED by its end at 4.14. KDE Plasma 4 lasted 6 years; KDE Plasma 5 is at least 9 years old is still a bug infested pile of manure that is barely usable, but not all is BAD at least I can at least do the same thing I was able to do in 4.14 even if I have to jump through a large number of hoops to get there. Too bad it took until KDE Plasma 5.18 to get to that point.

    8) DO NOT REINVENT THE WHEEL. LISTEN to your USERS. The MANAGEMENT of KDE Plasma 5 created a lot of ill will towards KDE. It was a POORLY MANAGED PROJECT. When USERS complained they were simply ignored, or given a pile of excuses.

    9) Since this is a NEW Project, before ANYTHING ELSE is done go back to KDE Plasma 4 and KDE Plasma 5 ands find out what USERS WANT. Start looking for people who Can WRITE a MANUAL and Can Provide PROFESSIONAL QUALITY VIDEOS that show Step-by-Step instructions on how to accomplish something.

    Finally you should create a LARGE BANNER that says: “A HAPPY USER IS OUR BREAD AND BUTTER, DON’T MAKE THEIR LIVES A LIVING HELL”

    Like

    Reply

    1. I love users who know everything better and dictate developers what they should do and what they must not do – especially if communicated in CAPITAL letters!!!!111eleven. 😛

      Liked by 2 people

    2. You appear to be a very unhappy person and appear to be using a totally different version of plasma. There is always room for improvement. But KDE & Plasma have been fine, polished and stable for a very long time. Please stop projecting your misery on others. I suggest, you should refrain from using any modern Linux desktop and environment and start using MSDOS again.

      Liked by 2 people

    3. Well, the transition from KDE 3.x wasn’t user friendly at all and it took a lot of time that the desktop became reasonably stable again – very, very late in 4.xx. Your tone isn’t helpful in this context.

      My experience over this time (latest stable KDE 5.x):

      Losses

      – Browser: The community understandably isn’t able to compete with Firefox or Google
      – Mail: I gave up on KMail long ago.
      – Office: KOffice does not compete either.

      Wins

      – The stability of the (X11 based) desktop is in my experience very solid nowadays.
      – KDE Connect

      Other stuff

      – My guess would be that KDevelop has lost momentum, but I neither so know or care.
      – The graphics and video applications in the KDE space are lacking in my exper1ence – on the other hand I’m not inclined to re-evaluate if there’s no compelling reason to do so.
      – I don’t care about Activities or Discover at all; in the former case I raise my hat for trying to offer an outstanding feature, though.

      Liked by 2 people

    4. I’m also unhappy with some of the decisions the KDE project took over the years, but your attitude is not helpful. KDE is mostly run by volunteers in their free time. Since Suse and Ubuntu stopped sponsoring their respective KDE-distros there are no more big commercial backers.

      If you miss documentation, be it written or videos, you can step in and create it yourself. That’s a task non-developers can do, too.
      The port to plasma 6 is necessary, because the Qt company, the company behind, well, Qt, the toolkit that KDE is built on, will stop supporting Qt5 soon. Already a lot of bugfixes in Qt6 are not backported to Qt5. KDE doesn’t have the manpower to also support the toolkit. Distros would stop shipping KDE, because it would be build on a insecure foundation (unsupported toolkit with known security vulnerabilities).

      In the end, somebody has to pay for the product “desktop environment”. You can either pay for a commercial desktop like Windows or MacOS, or you use a free desktop like Gnome, Mate, KDE, lxqt, etc. If you don’t pay with money, you pay with your time configuring it, working around bugs, reporting bugs, fixing bugs.

      But guess what, even the commercial systems have their problems. But unlike with free software, where you can always either fix it yourself or pay somebody to fix it for you, you totally depend on the software vendor to change its software to your liking. I’d rather have my software to my liking, knowing with enough time and money I can always change it, than having something forced on me, I can’t even influence. And we haven’t even started on “telemetry” in modern commercial software and how your data is shared with private companies and various states.

      Liked by 2 people

    6. Wow. You’ve been pig-biting mad at KDE for almost ten years. I would have given up and switched to another DE ages ago.. Then again, people that completely lose it on the internet is what makes internet fun, thanks for the laughs, super-boomer.

      Liked by 2 people

    7. Sorry somebody peed in your breakfast this morning Bob. I hope your life gets better.

      I’ve had no problems with plasma.

      Liked by 1 person

  4. One thing I noticed in the past after installing KDE5 is what felt like too many configuration entries into the root “~/.config” directory. I had a sense that many of these could have existed in subdirectories under that root folder (e.g. “~/.config/KDE5, or whatever.) In essence, creating some namespacing with some folders vs. having so many configuration files in the “root/global” namespace (using these terms loosely, but hopefully this make well enough sense.)

    I am not a KDE expert, so maybe one could argue these files are not in any way related to each other and therefore should not exist together in some subdirectories (e.g. Kate is independent from KDE, etc.) But, if what I say here makes some sense, maybe changing this in KDE6 would be a good time to do so. I mentioned this gripe a couple years ago in the Phoronix forum for a KDE article, and someone mentioned there was some talk of doing this.

    Just seems like a way to keep “~/.config” cleaner and less cluttered. I am not a regular KDE user, but I have long liked the clean and crisp fonts, icons, option for a traditional desktop paradigm, etc. But the issue above gave me an immediate bad impression. Anyway, just wanted to share my take, and again not a KDE expert here. Thanks!

    Liked by 2 people

    Reply

    2. This is one feature I would like to see: easier editing of configuration via config files in one location. Please.
      Of course, we don’t want a “registry” like some other commercial products, or even open-source DE’s.
      Thank you.

      Liked by 1 person

    3. It would be feasible for us move towards namespacing all KDE software such that the config files all live in ~/.config/KDE. I’m not sure how much that really gains anyone though, outside of being OCD about categorization.

      Liked by 1 person

    4. It’s not about “being OCD about categorization”, it’s about being able to easily tell which config file belongs to a KDE application. Believe it or not, not everyone knows the name of every KDE app by heart. Just dumping every config straight into `$HOME/.config` is no better than just dumping them straight into `$HOME` like in the dark ages.

      Liked by 1 person

    5. I have no doubt that it would be a nice thing to have, but you have to understand how incredibly niche of a thing this is. The files in question contain technical configuration data and live in a hidden location invisible to and undiscovered by the vast majority of users. Of the ones who do discover these files, most of them seem to have no opinion regarding potentially superior organization. The people who do are therefore a minority of a minority.

      Again, I’m not saying we shouldn’t do it or won’t do it, but it would be a lot of work (patches for every single piece of KDE software that exists) for a small benefit to a small fraction of users. In all likelihood, it will happen only when someone who REALLY cares about this makes it happen by organizing the effort and starting to submit patches.

      Like

    6. I have no strong opinion on the proposal, but it seems to me that the organization of configuration files in KDE is quite chaotic. I mean, I do have a ~/.config/KDE folder in my system, but it contains just one file. At the same time, I also have the folders ~/.config/kde and ~/.config/kde.org, plus all the other individual folders and files in ~/.config.

      I mean, it does the job, but it is impossible to navigate. For instance, it makes it incredibly difficult for someone to figure out which files should be deleted in order to reset the configuration of the whole KDE desktop or just a specific component.

      Config files are certainly not the most discoverable thing in the software world, but here it seems that individual developers are essentially choosing their own conventions, folder hierarchies, and naming schemes, with little coordination with the rest of the ecosystem. Perhaps some effort should be put into coming up with some guidelines that should span across the whole KDE project.

      Liked by 1 person

  7. Hi, Nate
    Can i say?:
    “The most interesting thing is that according to Nate, if things go as they should and everything goes well, there should be Plasma 6 between December 2023 and March 2024.”

    Like

    Reply

  8. If you increase the release cadence but don’t do anything to get more feedback the amount of total QA will remain almost the same, if not less.

    In my opinion Plasma needs more supported and semi-official ways of delivering Plasma-git to users.

    For example, how can I test drive Plasma6 with Arch?

    Like

    Reply

    1. Thanks for everyone’s efforts.
      Actually among Linux users in China. KDE Plasma is often praised for its excellent functionality and the powerful software that goes with it. Hope the developers can bring us a better KDE Plasma6 in the future. We will always support you.

      P.S. I agree with HackR. I am a ArchLinux user, and I want to test KDE Plasma 6 but I don’t have ways to test it unless installing another distribution.

      (I’m just a middle school student in China, please forgive me if there are any weird mistakes in my sentences)

      Like

    2. At the moment, Plasma 6 only very recently became usable as a daily driver, so there are not many options besides compiling everything yourself. Probably the best option at this point in time is to use Neon Unstable. A buddy of mine also has a Fedora COPR that you can use that’ll apply on top of Fedora Rawhide: https://copr.fedorainfracloud.org/coprs/g/kdesig/kde-nightly-qt6. I’ve also heard that KaOS has an ISO, but it’s two months out of date by now so I don’t recommend it.

      Hopefully more distro options will be appearing in the coming months!

      Liked by 1 person

  9. As per the usual, Nate – great work in KDE and great communicating.

    My thoughts:

    A. I’ve been trying to get into Plasma 6 live-aboard, but I’m having difficulties: neon unstable builds won’t even start due to segfaults in ksplash and a few other components, and kdesrc builds keep falling with random compilation issues: every couple of days I try again, get a compiler error (which I might try to do a manual fix and submit an MR, and move on to the next failure) and then I put it aside until I have more time. Is my experience different and weird?

    B. I’ve been trying to create a new KCM and I can’t find good documentation – the tutorial in techbase is woefully outdated (QWidget based, no KF5, etc) and all other documented examples I’ve found use kxmlgui and other old stuff. I tried reverse engineering some “simple” QML KCMs but it mostly flew over by head. I would really love it if – as part of the Plasma 6 KCM work – someone can just write up a very simple, basically empty KCM (with some lorem ipsum and buttons that say “your action here”) that developers can clone and use as a starting point.

    Like

    Reply

    1. For A, I think your experience is maybe not *that* weird; everything is still heavily in a state of flux. I’m not encountering those issues myself, but of course we’re using different hardware and different configurations. It’s possible the crashes are caused by remaining co-existence issues due to installed file conflicts between Plasma 5 and Plasma 6 components, which I won’t encounter because I have my 5 and 6 builds in different locations.

      For B, our QML KCM documentation can be found at https://develop.kde.org/docs/features/configuration/kcm/. The stuff on Userbase is old and outdated and should generally not be looked at anymore. We’re considering eventually removing Userbase after updating and migrating any content that’s still relevant?

      Like

  11. To the KDE developers:

    I’ve tried every-avenue-possible to make-sure this message Hera sent to the KDE developers. I’ve even tried emailing them at the email-address listed on the KDE Facebook page, despite not-knowing if that’s the-email-address to contact the-KDE-developers for feedback-&-suggestions on the KDE-Plasma desktop-environment.

    So now I am trying this-one ⬇️:

    I recorded this video-message with some suggestions-&-feedback on how they can improve the KDE “virtual-desktops” (ie. “Workspaces”) and the view they call “Overview”.

    Like

    Reply

  12. This all sounds like fantastic work! Can’t wait to try it!

    I’m curious about one thing. Will porting PlasmaCore and PlasmaExtras to Kirigami affect desktop widget theming in some way? Today Kirigami or QtQuick doesn’t seem to use themed widgets using Oxygen, Kvantum, QtCurve, etc and even with QQC-desktop-style installed most theme details and nuances – like Oxygens beautiful gradient backgrounds – are lost. Perhaps this is something that will be fixed eventually, but it would be sad if that kind of theming dissappeared. Especially since “You can make everything look like you want – not only change a few colors” still is the best sales pitch for me to get people to switch to KDE and Linux. 😀

    Like

    Reply

    1. The Kirigami units, durations, and colors are identical to their PlasmaCore versions, so there should be no visual changes whatsoever. If there are, we didn’t do the porting right. 🙂 I’m currently working very hard on QA to make sure there are no visual changes from any of these porting tasks.

      qqc2-desktop-style definitely does consume styling from your QStyle. For example buttons, text fields, and comboboxes in QML apps (not Plasma) should absolutely get the right styling even if you’re using Kvantum. It’s just that it can’t do *all of it;* the fact that backgrounds aren’t the same is a known incompatibility, and potentially something we might be able to fix. Maybe you can submit a bug report about it?

      Like

    2. Thanks for your quick answer Nate, as always! (And for your informative and exciting blog posts.) It’s good to hear your clarification. And as you say, buttons and some other things are indeed correctly styled. Sounds great to know more can be done, I’ll file a bug report! 🙂

      I also want to clarify I am in no way dissatisfied – I now these things are complex – I’m merely curious. You are all doing a fantastic job and I appreciate it immensely!

      Liked by 1 person

  14. Hi Nate, thanks for your amazing blogs. I have an idea for your posts.
    Can you dedicate a section in your weekly posts about Plasma 6 features and another section about Plasma 5 and other apps features?
    I think this way it will be clear which feature is for Plasma 6.
    Anyway thank you so much for your blog.

    Like

    Reply

  15. Hi all
    I have been a linux user for 12 yrs and used a verity of DE`s recently trying EDE , we have to remember KDE is funded by donations and guys doing there best , its going to have good and bad points , in the future i plan to donate to the project to help out with development ect , i always find i come back to KDE for my sole desktop in arch linux minimum install , we need to suggest new ideas and look forward and yes learn from mistakes , i would love to try plasma 6 as my main DE now also is there a site i can d/l from btw.

    All the best to the KDE team
    Regards
    Lord-Protector

    Liked by 1 person

    Reply

Leave a comment