Window decorations (fixes https://bugs.kde.org/show_bug.cgi?id=414113)

Not all decoration themes draw circles around decoration buttons, so that's probably CANTFIX. On the other hand, we could synchronize kwin's decoration button layout with the gtk-decoration-layout property.

In T10611#208756, @zzag wrote:

Window decorations (fixes https://bugs.kde.org/show_bug.cgi?id=414113)

Not all decoration themes draw circles around decoration buttons, so that's probably CANTFIX.

Could we sync that setting for those themes that do have this option?

In T10611#208756, @zzag wrote:

Window decorations (fixes https://bugs.kde.org/show_bug.cgi?id=414113)

Not all decoration themes draw circles around decoration buttons, so that's probably CANTFIX. On the other hand, we could synchronize kwin's decoration button layout with the gtk-decoration-layout property.

Some clever colour exporting would actually make respecting circle setting possible for Breeze GTK.

In T10611#208778, @ngraham wrote:

Could we sync that setting for those themes that do have this option?

Yes, you could do that. But keep in mind that you would have to hard code the list of those themes. KWin has no idea whether the decoration theme draws a circle around the close button.

We could also set the "Prefer dark theme" preference depending on your color scheme (like the filter combobox added in D18646).

In T10611#213118, @GB_2 wrote:

We could also set the "Prefer dark theme" preference depending on your color scheme (like the filter combobox added in D18646).

TBH, I can't tell if that setting actually does anything on Plasma.

In T10611#213121, @ndavis wrote:

TBH, I can't tell if that setting actually does anything on Plasma.

If you set a theme like Adwaita (if you're on neon you need to install gnome-themes-extra and set the GTK3 theme to Adwaita) that has a light and dark variant then it uses the dark one (see https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-application-prefer-dark-theme).

That's true; the colors KCM does actually identify dark-ish themes as being dark themes, so we could in fact set that checkbox according to your color scheme.

We have breeze and breeze-dark, adwaita and adwaita-dark in GTK Themes as options.

How are they supposed to work with this prefer dark theme option?

In T10611#213129, @GB_2 wrote:

In T10611#213121, @ndavis wrote:

TBH, I can't tell if that setting actually does anything on Plasma.

If you set a theme like Adwaita (if you're on neon you need to install gnome-themes-extra and set the GTK3 theme to Adwaita) that has a light and dark variant then it uses the dark one (see https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-application-prefer-dark-theme).

This appears to be indicative of a bug with the GTK KCM. Adwaita and Adwaita-dark always exist in GTK; the above themes package only installs a dummy theme. GTK will always use an internal copy of Adwaita/Adwaita dark if the theme is set to adwaita/adwaita-dark, regardless of the contents of the Adwaita in /usr/share/themes

I have tested prefer-dark-theme checkbox with Breeze and Adwaita themes.

Color scheme: Breeze Light

It seems like Breeze always grabs its colors from Colors KCM , while Adwaita colors depend only on Theme Name. Looks like this checkbox doesn't do anything.

Edit: It appears, that I've tested this with Lutris, that overrides the dark theme preference setting.

Still works for Adwaita:

EDIT: Arc as well.

Usually "gtk3 themes" downloaded from kde store via KNewStuff combine inside a GTK2 theme and a GTK3 one. Also, new Inkscape is using GTK3 and Gimp will eventually move to GTK3 too. Should we therefore unify GTK theme selection to only one option, that is independent on GTK version? Is there any use cases, where the user uses different themes for gtk2 and gtk3?

In T10611#215642, @gikari wrote:

Usually "gtk3 themes" downloaded from kde store via KNewStuff combine inside a GTK2 theme and a GTK3 one. Also, new Inkscape is using GTK3 and Gimp will eventually move to GTK3 too. Should we therefore unify GTK theme selection to only one option, that is independent on GTK version? Is there any use cases, where the user uses different themes for gtk2 and gtk3?

No, I don't think so. If GTK3 themes always include a GTK2 theme as well, your idea may make some good sense. But what about the use case where a GTK3 theme does not include a GTK2 version, but there is a GTK2 version on store.kde org that the user could otherwise manually apply?

But what about the use case where a GTK3 theme does not include a GTK2 version, but there is a GTK2 version on store.kde.org that the user could otherwise manually apply?

It would be nice to see an examples of this and many of them (not just one or two). I browsed store for GTK3 themes and literally every archive I opened includes directories gtk-3.0 and gtk-2.0, meaning that the themes are both for GTK2 and GTK3.

Also, it should be noted, that GTK themes are not only used on Plasma, but on Gnome, where you have ability to chose theme (from tweaks) without any separation of GTK2 and GTK3. Therefore theme authors ought to include the GTK2 version to make it work in GTK2 apps on Gnome Shell.

Nowadays pretty much all GTK3 themes have a GTK2 version, but a few years ago (and there is a good chance of some people using old themes) there were many that didn't have one. There could be also in-development GTK3 themes in use, that don't yet have a GTK2 version.

What happens if the user sets an "incomplete" theme that doesn't have a GTK2 theme (or something even scarier: a GTK2 theme without GTK3 variant)? A warning in System Settings would be nice. Should the user be forced to select another theme? Should it fall back to Adwaita or Breeze? Should the separate selectors appear in that case?

Also, should selecting a Qt app theme that has accompanying GTK themes (like Breeze, Adwaita and Deepin) auto-select the appropriate GTK themes?

! The follolwing paragraph is a rather long and pointless brainstorm of Kvantum theme integration, that only ties into this conversation at the end. Only read if you really want to hear my opinion on that, and you have the time and energy. Is there a separate task for that where we can have this discussion, so as not to hijack this thread?

That last question opens up a whole other topic, namely Kvantum Manager being semi-officially integrated into the Qt application style selector, so instead of just "kvantum" and "kvantum dark" (the latter of which is utterly redundant), the grid would include all Kvantum themes, and their Edit/Tweak button would bring up Kvantum Manager's "Customize active theme" page as a config dialog. Themes could be added from file just like in other KCMs, and the Get New Themes button would bring up Kvantum themes on KDE Store... And if the user selects a theme that has a GTK theme included (or there is a GTK theme with the same name on Pling/KDE Store), the appropriate GTK theme could be automatically selected, making the experience seamless. When a Kvantum theme is selected, a warning could appera saying "Kvantum themes are not made by KDE and might not look nice or work properly. Proceed with caution."

Nowadays pretty much all GTK3 themes have a GTK2 version, but a few years ago (and there is a good chance of some people using old themes) there were many that didn't have one.

The problem of the specific theme. The theme is old, it is no longer maintained and therefore cannot be used.

There could be also in-development GTK3 themes in use, that don't yet have a GTK2 version.

The problem of the specific theme. If the themes is yet in development, that means it is not production ready.

In T10611#217854, @ngraham wrote:

window decoration button orders

It has been already implemented (D25670). I just thought that somehow the shapes and colors of window decorations could be exported to breeze-gtk theme as images. so that I could have a breeze GTK theme alongside with the decorations of other origin. But that task seems to be more in @cblack competence, as it involves messing around with GTK theming CSS restrictions.

Ah I didn't even notice, perfect.