+1. Maintaining two sets of Plasma components in addition to Kirigami and our QQC2 style is a significant maintenance burden and I think many things would be improved by porting to upstream components or Kirigami.

We would need to make sure all needed features in Plasma components that are not yet upstream or in Kirigami get there. Additionally, we would need to discuss the issue of Plasma-specific theming. Right now Plasma components controls have a notably different appearance from QQC2/Kirigami components, which are general desktop-like (QQC2) or convergent and slightly mobile-ish (Kirigami).

It's my personal opinion that this separate Plasma-specific visual style for QML components is something we should move away from in the interests of general consistency, in a nod to the recently-chosen KDE-wide goal: T11093: Improve Consistency across the Board, and doing so would further reduce the maintenance burden of keeping up a Plasma QML style that's separate from the desktop and Kirigami styles.

In general I would also like to see this happen, but it would be nice to preserve theming capabilities or at least making QML styles easier.

In T11558#200735, @filipf wrote:

In general I would also like to see this happen, but it would be nice to preserve theming capabilities or at least making QML styles easier.

Yeah, we'll have to wait and see what Qt 6 brings.

In T11558#200737, @GB_2 wrote:

Yeah, we'll have to wait and see what Qt 6 brings.

Or a bit more proactively, get in touch with the Qt team, e.g. by attending Qt Contributor Summit (https://wiki.qt.io/Qt_Contributors_Summit_2019), and make sure our needs are considered :)

I will be at QtCS.

But this title and the comments don't make any sense. Plasma Components 2 and 3 are QtQuickControls 1 and 2 respectively. If anything it shows the QQC2 stuff (from a Qt side) is working perfectly, we're able to style them and have absolutely no control logic our side.

There's a few minor bits of API that would be nice, and a slight quirk with regards to choosing how we load a theme, but overall the whole system does work really well.

I think Nate is describing that we have the desktop style and the plasma style? But is that the original topic?

In T11558#204935, @davidedmundson wrote:

But this title and the comments don't make any sense. Plasma Components 2 and 3 are QtQuickControls 1 and 2 respectively. If anything it shows the QQC2 stuff (from a Qt side) is working perfectly, we're able to style them and have absolutely no control logic our side.

Well, the boundaries between "control logic" and "styling" may be blurred at times. For example I recently fixed a bug in PC3 (D24402) that I guess was technically a style issue, but from a user perspective felt like a control issue; the button didn't appear to work correctly.

The bug was only present in the PC3 button, not the QQC2 button. That's the kind of extra maintenance burden that I'm talking about.

I still don't follow what you want to change.

In T11558#205300, @davidedmundson wrote:

I still don't follow what you want to change.

Remove PlasmaComponents2 and PlasmaComponents3 so we always used controls from Kirigami or from QQC2 itself, styled from the QQC2-desktop-style theme.

Ok. Kill plasma components in favour of qqc2-desktop-style.

Not sure I agree, but at least we're speaking the same language now.

Heh, that's good. :)

In T11558#205304, @davidedmundson wrote:

Not sure I agree,

Can you expand upon that?

Let's discuss this some more. No need to rush. What's your opinion @mart?

• At one point it was a deliberate goal that the desktop looked different to apps.

• Dropping support for plasma themes breaks all the user created themes in the store (there's 550 of them)

• There's the issue of primitives. Plasma as a desktop makes use of the lower level FrameSVG class which is analogous to QPainter::drawControl doing the basic rectangles and shapes and whatnot, but following the theme. There's no equivalent in QQC, and I don't see how there can be, as it's deliberately high level.

• At a tech level, our QStyle implementation wrapper is very slow as it's a proxy layer with huge pixmaps. Though tech shouldn't necessarily dictate goals.

Then you start heading down the route of "lets come up with a new magic declarative solution that we use to power both QStyle directly and QtQuick directly" which has some nice advantages, but then instead of breaking 1 layer of compatibility issue, we break 2.

the simple fact is that we can't just dump all the custom plasma themes in kde-look.org, there are just too many users likeing, using and creating those.
especially, is a no-go replacing it with a completely inflexible, obsolete and hard to create/share system like QStyle
If that ever is to be done, a theme engine that can load styles which are mostly images and text files (so, sharable on the store) that works on both widgets and qml should be done

Crazy idea: can we do the opposite thing and deprecate QStyle in favor of something more flexible and share-able like the Plasma style--and apply it to desktop apps as well? Perhaps we could even deprecate separate widget styles entirely in Plasma 6 and say that apps and Plasma will just always have the same style (and then make sure that the Breeze theme looks good for both). I've never really understood the use case or desire to have Plasma and your apps look totally different from one another TBH.