to be discussed between KDE and Qt people, possibly at QtCon or specific sprint
- Mentioned In
- T13256: Come up with a solution for displaying QQC2 elements in Plasma
D27422: [KCM]Update Device item layout based on applet
D24720: [applets/systemtray] Rewrite popups with layouts
- Mentioned Here
- D24402: [PlasmaComponents3] Fix checkable toolbutton background
T11093: Improve Consistency across the Board
+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.
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.