Strong +1. Maintaining all these toolkits spreads out development resources more thinly for the (IMO dubious) reward of more bugs and visual/behavioral inconsistencies between our software.

So you want to remove plasma themes?

Generally I think we can all agree on doing away with QQC1 and PC2, however...

Port any remaining PC2 things in Plasma to PC3

This can't be the first step because not every PC2 thing exists in PC3. Also (from my experience) PC3 is not as polished as PC2 so that's two steps before everything can be ported to PC3.

Make everything that uses PC3 use the QQC2 Desktop Style

I'd rather not lose our Plasma theming, but apparently it might be possible to conditionally load either a Plasma or QtQuick style from the same component set.

I'd rather not lose our Plasma theming, but apparently it might be possible to conditionally load either a Plasma or QtQuick style from the same component set.

Legitimately one of the first things I suggested - I don't want to lose Plasma theming, either, TBH, but I'd rather that workflow is eased for development as well.

In T13075#228946, @filipf wrote:

Generally I think we can all agree on doing away with QQC1 and PC2, however...

Port any remaining PC2 things in Plasma to PC3

This can't be the first step because not every PC2 thing exists in PC3. Also (from my experience) PC3 is not as polished as PC2 so that's two steps before everything can be ported to PC3.

Then we'd better do that first. QQC1/PlasmaComponents2 aren't going to work in Qt6 anyway, so we have to do that the eventually.

In T13075#228941, @davidre wrote:

So you want to remove plasma themes?

Personally, yes--for KF6/Plasma 6. I think in KF6/Plasma 6 we should have a concept of a single KDE theme that affects both apps and Plasma. This is ultimately what I think most users actually want--for the entire system to look like macOS or the Star Trek LCARS computer (or super-blingy Deepin, or Fluffy Bunny, or whatever), but I'm not sure there's a sane use case for someone who (for example) wants Plasma to look like macOS but wants their apps to looks like LCARS. Having this difference and making them separately configurable is mostly annoying for the vast majority of users who want everything to look the same, and makes extra work for theme creators.

How will that approach handle visual differences between application controls and Plasma controls?
An example is Kubuntu's default theme combo, which I also use on my machine: Breeze (default, light) for apps and Breeze Dark for Plasma. Light apps and a visually distinct dark panel are not an esoteric combo, some other workspaces default to it, e.g.:

• GNOME

• ChromeOS

I'm also in favor of using QQC2/Kirigami in Plasma and getting rid of equivalent control types from PC2/3.

In T13075#229004, @IlyaBizyaev wrote:

How will that approach handle visual differences between application controls and Plasma controls?
An example is Kubuntu's default theme combo, which I also use on my machine: Breeze (default, light) for apps and Breeze Dark for Plasma. Light apps and a visually distinct dark panel are not an esoteric combo, some other workspaces default to it, e.g.:
[...]
On GNOME, while maintaining a separate look, the shell style is part of the GTK theme IIRC, but Is it possible to combine two distinct control looks in terms of a single QQC2 style? Especially when our style is, in fact, a bridge from QWidgets style, which is hardly something we can expect 3rd-party developers (except Kvantum) to work on?

I think a solution to that problem that still reduces the overall maintenance burden could be to let people choose a different QStyle and color scheme for plasmashell.
For Kubuntu, this would just mean it needs to set Breeze Dark as the color scheme for Plasmashell instead of using the Breeze Dark desktop theme (since it would no longer exist).
I expect that most people who want a highly customized widget style will use Kvantum for the Plasma theme. Most of those people would probably use Kvantum for their applications anyway.

This may be relevant to the conversation too: https://bugreports.qt.io/browse/QTBUG-68814

Native style support for Qt Quick Controls 2

We want to support native styling in Qt Quick Controls so that application UIs developed with controls look native on standard desktop environments. UIs that want custom look wouldn't use this, but instead utilize the existing styling support in Qt Quick.

The imperative rendering API that QStyle relies on does not work optimally in a scene-graph based rendering world, like Qt Quick. Instead, we want a styling technology that generates scene graph nodes (or something that easily can be made into scene graph nodes, like visual assets).

As a first step, we duplicate the existing QStyle implementations from QtWidgets as a private API into QtQuickControls, and refactor it to not have any QWidget dependencies. Good if in the long run we don't have this duplication, but might not be realistic to have a unified architecture for both worlds.

Atlas-based style. Needs information about sizes, alignment, etc.

Investigate cascading.

QPainter-based and scenegraph-based. This also means text rendering.

Floating point based API.

I see a use case for choosing a different color scheme for plasma vs apps, so it would make sense to expose that in the UI. I don't really see a use case for different widget styles though, but if we want that to remain possible, then I think Noah's suggestion could work.

Why go through QStyle then? We have much more Plasma themes and plasma theme can also be used a quick controls style. The only problem is that in Plasma we want to have two different styles in the same process which is currently not possible. Kai had the idea of a proxy quick controls style which would select the approbiate style plasma or org.kde.desktop depending on if something is part of the shell or not (like the config windows) but that needs investigation if that is possible/feasible.

When I said QStyle, maybe I should have been slightly less precise because I meant widget style. I don't know if going through QStyle would be absolutely necessary since Plasma is all QML, but I don't want us to have to maintain separate QQC2 and Qt Widget styles in the long term.

Individual status and blocked tasks are now tracked at: https://phabricator.kde.org/project/view/316/