Packaging it as a standalone binary for different platforms seems like a good plan. I have no idea how hard this might be to do though, sorry. But you can always propose it in one of KDE’s chat channels or mailing lists and see if it piques anyone else’s interest or they feel like helping you do it!

Accent-colored tinted window headers, touchpad gesture configurability

You’re very welcome! I’m happy you’re enjoying it.

from what I understand, you can only have them both installed (or none), not one or the other

You can have only one installed, and Fedora KDE ships this way. If your distro doesn’t offer that, it seems like a distro packaging issue.

make it easier to change file associations for common file types

That’s in Plasma 6. :)

That’s a fantastic idea. I’ve had the same thought myself.

One challenge with making it portable is that you need something that will work on any machine you plug it into. If there’s an emergency and you need the data on there when you don’t have your main computer, it’s likely that the machine you plug it into isn’t running Plasma. For this reason I think a hardware-encrypted flash drive with physical number buttons on it suits the use case better. That way you decrypt it with your fingers, and then the contents are readable on any random Windows, Mac, Linux, Android, iOS etc device you have to plug it into.

A challenge for integrating with Kvantum is that it isn’t great for theming QtQuick due to bugs in our existing creaky theming infrastructure, as well as development direction preferences on the part of Kvantum’s maintainer.

One thing we have planned and want to work on during the Plasma 6 lifecycle is a new unified theming system that can apply to all KDE and Qt apps, GTK apps, and Plasma. The idea is to have a new theme that can be directly consumed by Qt’s Qstyle (for QtWidgets apps), KDE’s QtQuick desktop style (for desktop QtQuick apps), KDE’s Plasma style (for Plasma), as well as KDE’s GTK theme. Essentially we would end up with a new theming engine and each of the existing themes we have would consume those themes. This would replace the current approach where the C++ QStyle is the central source of truth and our QtQuick desktop style pulls content from it, while our Plasma and GTK themes are totally separate and have to be changed manually.

The new proposal is in fact not unlike how Kvantum already works, but it’s not rally made for easy upstreaming and it also uses SVG as the basis for its themes. We’d like to build our own thing and investigate using CSS as the basis for themes.

Needless to say, this is not happening for Plasma 6.0. :) But I’m hoping we can get it done sometime in the next year or three.

whistles innocently

As a Board member now, I’ll answer this one. To a certain extent I ran for a seat on the Board because I realized that proposing this via a Goal was the wrong place to do it, and the more effective way to push for that change was by being on the Board. And now that I’ve been elected there, yes I do still want to do it and push for it internally where possible. However now that I have a fuller picture of the e.V.'s situation, I realize that there are budgetary concerns that must be met before we do more hiring, and KDE e.V. operates under extremely strict German nonprofit rules that make it not as simple as it might appear. Now, in an ideal world this person would be effectively self-funding, but we need to make sure we can afford them in the first place! It’s a bit of a chicken-egg situation, really.

Note that we’ve already done a certain amount of professionalizing KDE inasmuch as it means “KDE e.V. hires professionals to work on KDE.” KDE e.V. does indeed now employ multiple technical engineers to work on various areas of the software stack, and I want to see this grow even more. But, we need more money to make it happen, and until we do have that employed professional fundraiser, it’s up to existing members of the Board and the community to improve the revenue side of the equation so that it becomes possible! That’s why I’m so happy with the progress of the current fundraiser. 700 new members means at least 70,000€ of new recurring yearly income, which is enormous for KDE e.V. If we can keep up this kind of fundraising performance, we can do so much cool stuff in the next few years.

Sure, but Qt is the largest C++ toolkit in the world with millions of developers, so it’s not exactly a small niche thing that someone who knows C++ hasn’t heard of. :)

Something that’s often not mentioned is that C++ with Qt is often a very different beast to use compared to C++ with the stdlib and other GUI frameworks. IMO Qt takes a lot of the pain out of C++, such that the criticism becomes blunted and mostly articulated by people looking in from outside who haven’t tried it yet.

In fact there are already quite a few Wayland-only features. You can read about them on https://community.kde.org/Plasma/X11_Known_Significant_Issues.

Plasma Vaults! It’s the best implementation of having a little encrypted bucket to put your important files in that I’ve ever used, on any platform. It’s very well integrated into Plasma as a 1st-party supported feature, and it works wonderfully.

What’s the best or recommended way to test out Plasma 6 RC2?

Neon Testing in a VM (or on bare metal if you’re adventurous). Arch with the kde-unstable repo is good too, but that also includes a snapshot of the unreleased Qt 6.7 which introduces more bugs.

What has been the hardest problem to solve moving to Qt6?

Personally I’d have to say the large number of API and behavior changes in QtQuick that Qt 6 has brought. We use QtQuick very heavily throughout KDE, so this has required a lot of mandatory porting work, more than in our QtWidgets-based software. And there have even been changes between Qt 6.5, 6.6, and 6.7, so it’s still a bit of a moving target

Feeling just fine. :)

One of the most visible ones for me is that most common multimonitor workflows Just Work™ in the Wayland session now. There are still edge cases, but we’ve put a huge amount of effort into this.

Actually Plasma is generally more popular than GNOME every time surveys are conducted. However we have to keep in mind that the direct consumers of a DE are actually not the end users, but rather the distributors who package and distribute it. There are a number of historical reasons why many distributors ended up picking GNOME over Plasma including accessibility, corporate sponsorship, an easier packaging experience, and the rocky KDE 4 rollout burning a lot of trust. So what you end up with today is many distros shipping GNOME despite pent-up desire for Plasma. It’s a great illustration of how you need to keep your direct users happy.

And I think that pent-up desire is being unleashed these days due to various changes in our ecosystem. Plasma is better than ever and version 5 had a much less painful release compared to 4, with us aiming to do even better in Plasma 6. We also see an increasing number of hardware vendors shipping devices with Plasma on it (https://kde.org/hardware/), who had a strong financial incentive to listen to their customers by picking Plasma over GNOME. In addition, KDE’s accessibility game is ramping up hugely, and we have more robust corporate sponsorship than we used to with Valve and Blue Systems putting tons of resources into KDE. Finally, GNOME seems to be becoming more hostile to their downstreams, causing them to need to do more of their own development or else migrate to be a fork or skin of Plasma. Interesting developments.