August Plasma 6 progress update

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:

In the future we also plan to investigate moving the remaining bottom buttons elsewhere, so that KCMs can have no footers at all

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!

38 thoughts on “August Plasma 6 progress update

  1. Very encouraging progress!

    Regarding funded development, has there been any consideration towards employing someone to whittle away at those high priority and 15 minute bugs? I think this could be an excellent use of the money.

    Also, and this probably won’t fly – but I think Papirus would make an excellent default icon set for Plasma. Complete, clean, works well for both small and large icons and under consistent active development.

    Like

    1. I’d love to hire a dedicated bugfixer, but we need more money first, or to trim some personnel which wouldn’t be ideal.

      Like

    2. If you are interested in fixing bugs and porting and getting paid for it, you can apply for funding to do it.

      For example, NLnet funds open source projects with minimal paperwork. It has funded KDE projects before. Proposals to make existing projects attractive to more people are very welcome.

      There is no need to ask for permission from KDE to ask for this funding, but you can certainly discuss your plans in the community.

      Here is the short form to apply:

      https://nlnet.nl/propose/

      The next deadline is October 1st, which is sooner than you think.

      Liked by 1 person

    3. Jos brings up something very important. Individual people can apply for grants to work on KDE things, and it’s quite feasible for them to get funded! Several KDE people I’m aware of are already doing this, in fact. It’s easier for an individual with a discrete project to be funded in this way compared to KDE e.V. itself, due to the overhead of us needing to hire for the work using the grant funds and manage that person. An individual who receives such funds can just start doing the work immediately and self-manage!

      Check out https://community.kde.org/Make_A_Living. KDE e.V. is available to help out with writing grants.

      Like

    4. Maybe bug bounties can work, if you don’t have it already. (I moved back to kde this week, after a very long unity stint, I am soooo hapy to be back home)

      Liked by 1 person

  2. > For example the Autostart KCM is undergoing heavy changes right now as the result of some excellent volunteer contributions

    Thenujan feels proud 😁

    Liked by 1 person

  3. Nice. Looking forward to the new features implementation. Widgets getting more tidied up in general would be great- been trying to bake my settings to an immutable image and widgets can be annoying to configure.

    Also, I saw something on bringing SDDM into KDE? Considering the chance that Plasma 6 brings with breaking changes, is there a chance that it could be ported to use /etc or /var/ so that it could work in immutable systems?

    Very good news overall, regardless.

    Like

    1. Bringing SDDM into KDE is the plan of record, yes. It might or might not happen in time for Plasma 6.0, but if not, we’ll be targeting a subsequent Plasma 6 release.

      Is there a bug report describing the problem?

      Like

    2. I think this is the bug report: https://bugs.kde.org/show_bug.cgi?id=454509

      Other than that, it has been talked every now and then among immutable OS community. Fedora Kinoite was the first to really run into the issue. The other thing that runs into immutable OS limitation is the bootloader/plymouth KCM, but that one isn’t as essential or part of a Global Theme, so it’s probably fine?

      Liked by 1 person

  4. Great work, and thanks as always for the updates. But, you forgot to mention the most important thing: miller columns in dolphin!

    Like

  5. Hi, Nate!

    As always, thank you for your work and these posts!

    I’d like to try to help with development but I can’t use Neon or its repos (either bare metal or VM). But I’m on Ubuntu. Is kdescr-build (or perhaps something that might be succeding it) still working and with up-to-date doc that would allow me to run plasma from source?

    Thank you, in advance.

    Like

    1. You don’t need kde neon to build plasma. kdesrc-build is still working really well and the documentation is good enough. If you get stuck somewhere you can always ask in the matrix development group or the telegram group

      Liked by 1 person

  6. Why not to integrate Weston compositor for Wayland Plasma environment that is already provided of explicit sync maintaining Kwin just for Xorg PLASMA environment? It would be useful for Vulkan, Wayland and graphical drivers synchronization because all based on explicit sync. So, Vulkan could be used by default in rendering and compositor in Wayland Plasma environment.

    Like

    1. If we abandoned KWin in favor of using Weston as our compositor, we’d lose the enormously vast assortment of features that KWin has that Weston doesn’t. That includes X11 support, so this would make Plasma Wayland-only. So for a variety of reasons, it’s not feasible.

      Liked by 1 person

    2. If we did that, then the Plasma Wayland session with Weston would be missing 500 features that KWin offers in the X11 session–features like the Overview and Desktop Grid, Window Rules, tiling, blur, animations for window opening and closing and window maximizing and minimizing, fancy Alt+Tab switchers, and of course the most important one: wobbly windows.

      Hopefully it should be clear how losing all of these features all at once would be a poor strategic decision.

      Liked by 3 people

  7. I need hope. Tell me why I’m an idiot.

    Go wild with the insults. Just… answers… please…

    Google’s WEI got mentioned a lot in 2 KDE web reviews already. But why is there no mention of UK being ready to pass laws to force government spyware on all devices? The latest review has a link to an article from the FSF, and below it, a comment saying it will hopefully start an effective campaign against WEI. The FSF has recently pinned a call to action against backdoors as well (why doesn’t anyone else pin similar calls?). There’s no way the author is clueless about this backdoor danger…

    Like

    1. This government couldn’t organise a piss up, except to get caught doing it during a lockdown. Spamming blogs that are about other things won’t achieve anything.

      Like

    2. I don’t think you’re an idiot, and maybe this threat really is the big one. But I’m skeptical because you freaked out about 100 previous things that turned out to be a whole lot of nothing. It’s like the boy who cried wolf, right? Can you see that?

      But here’s the reason: I don’t feel that this is my fight. There are only so many hours in the day and only so much mental bandwidth available to care about important issues, and this issue isn’t one that I’m passionate enough about to spend my time and energy doing something about it.

      It’s clear that you are one such person. And I know that you think this issue is literally the most important thing and you can’t understand why anyone else wouldn’t share that opinion, right? That’s why it’s your fight! You have the passion and energy to fight it that I do not. You need to use that energy to do that fighting, rather than trying to convince me to do it for you. I’m not going to, sorry. It’s not my fight. You care about it, you do the fighting.

      Liked by 1 person

    3. Thanks a lot! Thanks a bunch! Thanks a ton! Thanks a million!

      I still don’t fully understand this answer, so can I ask a few more questions? And please forgive me if it sounds like I’m asking for too much, I really don’t mean to, I just want to know…

      > It’s like the boy who cried wolf, right? Can you see that?

      Yes, I see that now.

      > I don’t feel that this is my fight.

      When I say “you,” I usually mean KDE as a whole, and KDE Vision says that freedom without privacy isn’t really freedom at all and that KDE aims to change the world, it’s consistently reaffirmed, and the recent KDE for Activists page even explicitly states that KDE will fight for privacy.

      That’s why I’m so worried that KDE isn’t speaking up, and why I’ve been posting so much lately.

      > You have the passion and energy to fight it that I do not.

      I wish I lived in a democratic country like you…

      > It’s not my fight.

      I understand. But if nobody else in KDE wants to speak out, why not just… say it? Swap out KDE Vision with something like “we make awesome open-source software,” and announce the change. Make it clear that your software will still prioritize privacy within the legal limits, but you’re just not up for the fight.

      Maybe this announcement could even be the thing that starts something. Though, honestly, I don’t think it will, since it seems like nobody else has the energy to fight anymore…

      Like

    4. I mean, you don’t live in North Korea or China or Russia, right? If not, then you most likely live in a country that’s got free enough internet that you can still use it to organize and protest and stand up for what you believe in without the thread of being jailed or disappeared for it.

      Yes, KDE as a whole cares about online privacy, and we do what we can within the umbrella of the software we write. And if I were a person who cared about that topic more personally, I could use my position on the board of directors to advance it more and faster.

      But again, I’m not that person, and KDE is a lot bigger than just me. And anyway, you don’t need to be a board member to make things happen in KDE, or anywhere, really. Change generally comes from the bottom up anyway.

      To the extent that the board gives you a megaphone for whatever position you care deeply about, another person could very reasonably challenge me or someone else in the next board election on the platform of taking online privacy more seriously and using the position to lend gravitas to activities that draw attention to and fight against them. We’re a democratic body; that’s 100% possible and even encouraged. If the membership would prefer that and votes on it, then the system is working.

      But if you want my honest opinion about this matter, I would say that in my opinion, protests and boycotts don’t work. I think long ago democratic politicians figured out that protests are noise they can safely ignore because activists get bored and burn out quickly. To change their’ minds, I think you need to either work very closely within the system (lobbying, organizing IRL letter-writing and face-to-face meetings with legislators, etc), or very far outside of it (mass civil disobedience, “direct action”, etc).

      Like

  8. Nate, you mentioned that work on new features will start soon, and will work on updating the visuals and design start soon?

    Like

    1. We’re not planning any major Breeze them changes for Plasma 6.

      However there are some planned design changes surrounding existing UI layouts, and some of these are already merged for Plasma 6. Others are still pending, such as one I just submitted a few yours ago: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3155. There’s also a very cool design change proposal for Discover that I plan to start working on soon-ish: https://invent.kde.org/plasma/discover/-/issues/27#note_726754

      Like

    2. My 2 cents, But I do think the overall Breeze would be vastly improved if they just removed all of those unecessary separating lines everywhere in the UI. Like in one of the screenshots of the settings app, that line between the hamburger icon and the “Plasma Style” text. Also, the bottom border line separating the header from the main content. Colors and padding should be prefered method of separating elements and indicating where sections begin/end

      Like

    3. Yeah nobody likes that line! 😀 We all want to get rid of it, but it turns out to be a fairly stubborn line that’s deeply embedded! Removing it is not so easy, so this has taken a backburner to other things.

      Like

  9. Thanks for the awesome work, everyone.

    I wanted to comment about the KCM footer changes mentioned: it’s great to see the double footer disappear – but I don’t feel the same about the “Apply”, “Reset” etc buttons: the whole GNOME style concept of moving every action to the header is brain-dead, IMHO – when people operate dialogs, they do so from top to bottom: review quick actions at the top; do something interesting in the middle; apply changes at the bottom. The GNOME way of going top->middle->back to the top is broken and confusing and I would be loath to have KDE go that route.

    Like

    1. So my current idea is to move the infrequently-used Defaults button to the hamburger menu, and to hide the Reset and Apply buttons entirely so that there’s no footer. Then, when you change any setting, a footer will dynamically appear again with the Reset and Apply buttons on it, and go away again when you click one of those buttons.

      So the Reset and Apply buttons would still be located at the bottom of the page, but the footer they live on would simply be hidden when not needed.

      Anyway, it’s just an idea at this point, I haven’t done anything concrete about it yet, not even formally proposed it!

      Like

  10. Hi, and thank you for your work.

    I have a question. I personally don’t like menu (kickoff, kickerdash) button on panel, so I’ve removed it. But I’d like to open kickerdash with the hotkey. It’s not possible for Plasma 5 without hacks (like running it minimized with `plasmawindowed` or placing it on the desktop somewhere) or I havn’t found a proper way. Is there a possibility to add such functionality to Plasma 6 — open kickerdash with hotkey without need for it’s button to be visible. Maybe hide widget on the panel, but keep it existing (would became temporary visible when panel is edited).

    Like

    1. Widgets have to exist somewhere to be activated. It sounds like what you’re after is more of a full-screen KWin effect, much like Overview.

      Like

    2. Well, not exactly. Overview gives currently opened windows & desktops. I want visual dash launcher (usually I use klauncher but sometimes I’d prefer something fancy looking). I understand that widget have to exist to be activated. I just interested in some way to hide it: e.g. hide option near “Delete Widget” — so widget would visible in Plasma Editing mode, but hidden in regular mode. Or maybe some widget (subpanel?) that could have its own child widgets and would be hidden in regular mode.

      Like

    3. Maybe it’s possible to add kickerdash to tray widget, so it’s entry could be set as “always hidden”, so it would exist but not take place in panel.

      Like

Leave a reply to Franco Cancel reply