to be discussed between KDE and Qt people, possibly at QtCon or specific sprint
+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.
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?
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.
- 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.