If this also gets integrated into Kirigami as well, that'd be even better.

In T13467#236621, @The-Feren-OS-Dev wrote:

If this also gets integrated into Kirigami as well, that'd be even better.

I don't think this would be integrated into Kirigami. Rather, Kirigami would get its theming from the QQC2 style.

In T13467#236623, @ndavis wrote:

In T13467#236621, @The-Feren-OS-Dev wrote:

If this also gets integrated into Kirigami as well, that'd be even better.

I don't think this would be integrated into Kirigami. Rather, Kirigami would get its theming from the QQC2 style.

...which'd technically still be the Plasma Style?

In T13467#236628, @The-Feren-OS-Dev wrote:

In T13467#236623, @ndavis wrote:

In T13467#236621, @The-Feren-OS-Dev wrote:

If this also gets integrated into Kirigami as well, that'd be even better.

I don't think this would be integrated into Kirigami. Rather, Kirigami would get its theming from the QQC2 style.

...which'd technically still be the Plasma Style?

yes

IMO using SVGs for theming is something we should move away from in Plasma 6.

For most users, the editability advantage of SVGs is outweighed by the fact that most users will never be editing themes in the first place.
For users advanced enough to work on their own themes, the awkwardness of editing SVGs with a graphical program and not mangling magic IDs outweighs the ease improvement for non-advanced users.

IMO it would be beneficial to move to the universal language of styles: CSS. This is the styling language used by toolkits such as GTK, UWP, Clutter, Avalonia, among others. It is straightforward to edit, easy to maintain, and most importantly: not fragile.

Personally I also prefer CSS in the abstract. But if we do that, we're orphaning the entire universe of Plasma themes. The idea of "SVG themes everywhere" was to be able preserve them going forward.

I wouldn't be opposed to using CSS and then hacing both Plasma and Widgets apps read the CSS themes, but we'll have to then basically abandon the existing Plasma themes.

If we had a special CSS function for using SVGs as a frame background, it would be possible to reuse a lot of assets from Plasma themes, easing porting.

Hmm, that's an idea that bears investigation.

Here is another alternative proposal:

I personally would prefer if we were using native QQC2 style, instead of creating QQC2 theme engine. QML is easy to edit, and it would allow for greater freedom for theme developers. This would also allow us to stop using QPainter for drawing qml apps and we should get some performance improvements. QQC2 native theme would also allow the theme developer to create animations. Maybe the current Plasma theme engine could be preserved for legacy compatibility.

For widget apps, considerating that new widget apps aren't developed much these days, Breeze with some tweaks is probably fine. We should just make sure that the default QQC2 and widget theme are similar.

As for the CSS proposal, while interesting I'm not sure this would work. CSS works a lot with DOM hierarchy in a way that I don't think is possible for QML.

I think any new theming engine needs to universally apply its theme (particularly the window decorations and in-app decorations for dockable controls) to GTK as well as Qt. Too many major applications are GTK and not going away. The current theme engine is next to useless as GTK apps aren't affected by changing the standard theme.

I remember seeing someone had written some excellent scripts to automatically generate the GTK theming from the current Plasma settings -- I cannot find this again, but it looked impressive, and for some unfathomable reason I think (?) it had been rejected.

Other things often overlooked is that the current window decoration doesn't apply to in-app to dockable controls. Nor does changing the window decoration change the system svg icons where the window decorations are duplicated (the system svg icons are used in the menu under the icon for every window).

Also, I think too many features are currently baked into the Breeze theme, rather than being part of the theming engine itself.

For example, I liked the Plasma 5 Breeze theme, but not the window decoration icons. Therefore I tried to make a new window decoration for Plasma 5, but in order for it to be consistent I had to do a LOT of work, and eventually gave up distributing it because it required changes in so many places. The following image illustrates everything I had to change:

1. Edit Breeze kdecoration to change the QPainter window decorations in Qt apps (also had an an Aurorae theme which affected this bit only but wasn't as nice)
2. Edit Breeze kstyle to change the in-app dockable control "window decorations"
3. Edit Breeze-gtk SVG icons for window decorations in some GTK apps like Gedit
4. Edit Breeze-gtk python script which uses Cairo to generate PNG images for other GTK apps like Chromium
5. Edit Breeze-icons SVG files to change window decorations for options in window menu

I probably overlooked how to change the in-app dockable control "window decorations" for GTK apps. But certainly, things like the SVG icons set could also be generated automatically for a new window decoration.

Another option we've discussed is migrating to a CSS-based system like GTK has. If we do this, it would be worth coordinating with them and potentially just lifting their system and proposing it as a freedesktop standard for which we would then add support. This would allow a single CSS theme to theme both Qt and GTK apps, with obvious benefits. This could have some side effect benefit in that the GNOME people would gain a disincentive to break their theming based on convenience as this would be breaking the spec too.

In T13467#249508, @ngraham wrote:

Another option we've discussed is migrating to a CSS-based system like GTK has. If we do this, it would be worth coordinating with them and potentially just lifting their system and proposing it as a freedesktop standard for which we would then add support. This would allow a single CSS theme to theme both Qt and GTK apps, with obvious benefits. This could have some side effect benefit in that the GNOME people would gain a disincentive to break their theming based on convenience as this would be breaking the spec too.

I don't think GNOME is very interested in trying to do cross desktop or cross toolkit theming. I think they're currently focused on reducing maintenance burdens, flexibility to pursue any designs they want, making it easier to design an app that follows the GNOME HIG and making it easier to keep it looking how it was designed to look. I know one GNOME dev doesn't represent the whole, but I've also seen one say that they'd rather see KDE apps use and be designed for KDE specific theming rather than try to look native on GNOME.

In T13467#249433, @paulm wrote:

I think any new theming engine needs to universally apply its theme (particularly the window decorations and in-app decorations for dockable controls) to GTK as well as Qt. Too many major applications are GTK and not going away. The current theme engine is next to useless as GTK apps aren't affected by changing the standard theme.

I have a strong feeling it won't happen like that. Not because nobody wants it, but because it would be too difficult, technically and politically. Qt Widgets and Qt Quick don't render GUIs in the same way, but at least it's possible to make them look similar to each other. GTK folks would have to agree to implement the same graphical features that we have in a way that is compatible with how what we have behaves and it would mostly be for KDE's benefit since GNOME probably wouldn't use our theming engine. GTK isn't that concerned with looking native in non-GNOME based environments, so it would probably be an uphill battle.

I remember seeing someone had written some excellent scripts to automatically generate the GTK theming from the current Plasma settings -- I cannot find this again, but it looked impressive, and for some unfathomable reason I think (?) it had been rejected.

I haven't heard of this thing, so please provide a link if you can find one. If it was rejected, it was probably because it was too slow or it depended on something that wasn't stable (guaranteed not to change). As I said, I haven't heard of it, so I could be wrong.

Other things often overlooked is that the current window decoration doesn't apply to in-app to dockable controls. Nor does changing the window decoration change the system svg icons where the window decorations are duplicated (the system svg icons are used in the menu under the icon for every window).

It's not overlooked, it's just not currently possible. Those dockable control decorations have to be handled by the application style.

The window decoration could try to use icons from the icon theme, but not vice versa. I don't know the original reason why breeze window decorations don't use the system icon theme, but I suspect it has to do with the way icons would have to be scaled, maybe animations and maybe performance.

Also, I think too many features are currently baked into the Breeze theme, rather than being part of the theming engine itself.

For example, I liked the Plasma 5 Breeze theme, but not the window decoration icons. Therefore I tried to make a new window decoration for Plasma 5, but in order for it to be consistent I had to do a LOT of work, and eventually gave up distributing it because it required changes in so many places. The following image illustrates everything I had to change:
{F9720521}
Changes required just to get a consistent window decoration otherwise in-line with the Breeze theme:

1. Edit Breeze kdecoration to change the QPainter window decorations in Qt apps (also had an an Aurorae theme which affected this bit only but wasn't as nice)
2. Edit Breeze kstyle to change the in-app dockable control "window decorations"
3. Edit Breeze-gtk SVG icons for window decorations in some GTK apps like Gedit
4. Edit Breeze-gtk python script which uses Cairo to generate PNG images for other GTK apps like Chromium
5. Edit Breeze-icons SVG files to change window decorations for options in window menu
   
   I probably overlooked how to change the in-app dockable control "window decorations" for GTK apps. But certainly, things like the SVG icons set could also be generated automatically for a new window decoration.

The complexity here is unfortunate. As I said, icons could be made a bit more unified by only using icons from the system icon theme, but that has tradeoffs (scaling can't be as dynamic and flexible as QPainter, animation is harder or unsupported, SVG rendering isn't as fast. Maybe the tradeoffs would be worth it, maybe not. Depends on how much we want to take advantage of what QPainter can do.

In T13467#249534, @ndavis wrote:

I don't think GNOME is very interested in trying to do cross desktop or cross toolkit theming. I think they're currently focused on reducing maintenance burdens, flexibility to pursue any designs they want, making it easier to design an app that follows the GNOME HIG and making it easier to keep it looking how it was designed to look. I know one GNOME dev doesn't represent the whole, but I've also seen one say that they'd rather see KDE apps use and be designed for KDE specific theming rather than try to look native on GNOME.

You're probably right. Still I would like to reach out to them anyway just to get a formal opinion on record. If they're not interested, we can move forward with something that works for us, unburdened by the nagging feeling that we should have tried to do it in a cross-desktop way.

I remember seeing someone had written some excellent scripts to automatically generate the GTK theming from the current Plasma settings -- I cannot find this again, but it looked impressive, and for some unfathomable reason I think (?) it had been rejected.

I haven't heard of this thing, so please provide a link if you can find one. If it was rejected, it was probably because it was too slow or it depended on something that wasn't stable (guaranteed not to change). As I said, I haven't heard of it, so I could be wrong.

I found it and I was mistaken! It has been merged in the latest release and is the excellent kde-gtk-config project at https://invent.kde.org/plasma/kde-gtk-config

More specifically for GTK client-side window decorations https://invent.kde.org/plasma/kde-gtk-config/-/merge_requests/2 . I didn't notice it working because there was a bug in it with my particular Aurorae theme, but works for most of them now applying Aurorae Window Decorations automatically to GTK.

Other things often overlooked is that the current window decoration doesn't apply to in-app to dockable controls. Nor does changing the window decoration change the system svg icons where the window decorations are duplicated (the system svg icons are used in the menu under the icon for every window).

It's not overlooked, it's just not currently possible. Those dockable control decorations have to be handled by the application style.

The window decoration could try to use icons from the icon theme, but not vice versa. I don't know the original reason why breeze window decorations don't use the system icon theme, but I suspect it has to do with the way icons would have to be scaled, maybe animations and maybe performance.

I think it would make sense to somehow align the configuration of icons used for the Window decorations with those used in the system icons and with in-app dockable controls.

I also think that Aurorae Window Decoration themes could be improved by allowing the system colours to change the theme properly; Aurorae could also do with having the same shadow options that are in the Breeze QPainter theme. Either that or move to the QML theming system used for the likes of the "Plastik" theme and make this type of theme downloadable from the Get New Stuff dialogue.

This may be the wrong place as this might be more from a settings configuration vs theme features thing. If so feel free to ignore/delete.
These are things that I think would really make KDE theming great:

• Highlight color selection that works for both plasma and application themes, which unifying should likely fix.
• Transparency and blur adjustment for certain components, like sidebar, title bar, toolbar. Lightly is an interesting proof of concept.
• With above in mind, make sure blur and shadows can respect the shape of the window corners of said theme. The pointy corners in KDE are quite an eye sore.

One other important thing that hasn't been mentioned is that any new theming engine should be HiDPI aware. Currently, with regards to Window Decorations, I have not found a single Aurorae window decoration which renders flawlessly without adjustment across multiple DPIs.

I merged some related tasks into this since they boil down to the same discussion

Another option that we've been discussing recently:

1. We make a universal theme of some sort (using CSS, QML, or something else; exact format TBD)
2. We make a QStyle that is essentially a Kvantum-style theming engine that consumes the universal theme and applies it to Widgets-based apps
3. We make a QQC2 style that consumes the universal theme and applies it to QtQuick software, including (optionally) Plasma, without going through QPainter or the QStyle at all
4. We keep the existing Plasma QQC2 style that knows how to consume existing SVG-based Plasma themes, for compatibility's sake
5. We add a user-facing setting for apps to allow people to choose whether to have:
   • Their apps use the universal theme
   • Their apps use a different QStyle, such as Lightly or Kvantum
6. We add a user-facing setting for Plasma to allow people to choose whether to have:
   • Plasma use the same universal style as their apps
   • Plasma use a different universal style from the one being used for their apps
   • Plasma use an SVG-based Plasma 5 theme, which we deprecate in Plasma 6 but continue to support
7. In Plasma 7, we sunset support for SVG-based Plasma themes as well as generic QStyles (including Kvantum!) and only support the new universal theme--whatever it is we come up with

In T13467#254255, @ngraham wrote:

Another option that we've been discussing recently:

1. We make a universal theme of some sort (using CSS, QML, or something else; exact format TBD)
2. We make a QStyle that is essentially a Kvantum-style theming engine that consumes the universal theme and applies it to Widgets-based apps
3. We make a QQC2 style that consumes the universal theme and applies it to QtQuick software, including (optionally) Plasma, without going through QPainter or the QStyle at all
4. We keep the existing Plasma QQC2 style that knows how to consume existing SVG-based Plasma themes, for compatibility's sake
5. We add a user-facing setting for apps to allow people to choose whether to have:
   • Their apps use the universal theme
   • Their apps use a different QStyle, such as Lightly or Kvantum
6. We add a user-facing setting for Plasma to allow people to choose whether to have:
   • Plasma use the same universal style as their apps
   • Plasma use a different universal style from the one being used for their apps
   • Plasma use an SVG-based Plasma 5 theme, which we deprecate in Plasma 6 but continue to support
7. In Plasma 7, we sunset support for SVG-based Plasma themes as well as generic QStyles (including Kvantum!) and only support the new universal theme--whatever it is we come up with

How would removing the option to set QStyles improve the functionality of the Universal theme? I know that the universal theme is going to be superior to QStyles, but styles are the only way to make a Qt theme that's available for all desktop environments. Removing this feature for KDE would guarantee desktop fragmentation regarding Qt themes the same way every desktop environment has a different system for default apps.