kill plasma components in favour of qqc2-desktop-style
Open, Needs TriagePublic

Description

to be discussed between KDE and Qt people, possibly at QtCon or specific sprint

knauss created this task.Sep 9 2019, 9:14 PM

+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.

ngraham added a subscriber: Plasma.
filipf added a subscriber: filipf.Sep 16 2019, 8:29 PM

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.

GB_2 added a subscriber: GB_2.Sep 16 2019, 8:32 PM

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.

ognarb added a subscriber: ognarb.Sep 16 2019, 9:38 PM
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?

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.

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. :)

ngraham renamed this task from kill plasma components in favour of QtQuickControls2 + kirigami to kill plasma components in favour of qqc2-desktop-style.Oct 21 2019, 10:17 PM

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.

ndavis added a subscriber: ndavis.Sun, Nov 10, 8:27 AM