Remove Q_SLOT keyword from load and add override to destructor

Replace themeUpdate redundant signal with direct load call.

Undo previous hasty decision

Replace include gtkpage with forward declaration

Remove unnessary include and containsTheme function

Do not init GtkPage*, if the kded module is not loaded

Simplify GTK3 Preview algorithm

Remove forgotten signal connections

Replace dbus signals with dbusinterface calls

Taking advantage of the GTK_THEME environment variable would be a more elegant solution

On the other hand this does not work for GTK2 applications, so I'll leave it as it is.

• Fixed combobox selection after theme deletion (please test)
• Minor code style changes

In D26261#589834, @cblack wrote:

Code-wise, all of the stuff touching GTK looks fine except for the overengineered GTK3 theme preview, but that's relatively minor since it should still work as intended.

In D26261#589829, @ngraham wrote:

Everything works

In D26261#589827, @ngraham wrote:

I don't know if this is a bug in the KCM or a bug in the GHNS dialog, but when I delete a theme from the KCM, it's still listed as installed in the dialog. However when I delete a theme from the dialog, it disappears from the KCM as expected.

Do not display error, when the theme archive selection is canceled

It doesn't need to instantly apply it, but it should select Breeze and mark the state as dirty so the Apply button becomes enabled.

• When you delete the current theme, the combobox becomes empty. It should probably go back to the default theme or Breeze or something.

So, it needs to select Breeze in otherwise empty combobox and instantly apply it?

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.

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?

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?

May be tabs would be the solution? (This is mockup)

In D26261#584037, @ngraham wrote:

Everything that's left here could easily fit into a popup on that KCM, or we could use the multi-page KCM system to put all of this stuff on a sub-page on that KCM.

By the way, I've already made a popup in Applications Style KCM. Personally I have no objections whatsoever on that style and would gladly use it.

Rebase on master

@broulik do I need your revision to land this?

Rebase on master

In D25670#579888, @apol wrote:

This looks like it's trying to change configurations from other sources. This feels wrong.

In D25945#577677, @cblack wrote:

For flatpaks not respecting the setting preference, have you checked that the dark theme variant is installed?

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

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

In D25703#571286, @ngraham wrote:

Nice, works great. Wanna remove the option in the KCM in this patch too?

• Change appmenu to icon

• Use KConfigWatcher instead of KWin dbus signal

In D25670#570517, @cblack wrote:

You would probably want to use icon instead of menu, as menu is only rendered as a fallback for a pattern that most GNOME applications don't use nowadays.

Edit: Additionally, GTK apps that use an appmenu typically override the window decoration layout to reflect this. If they don't, then that's an issue on their end.

It changes config correctly now (instead of empty cursor theme name, that was before), but somehow cursor does not change until I manually change the cursor theme in Cursors KCM.
Very strange.

Did I understand correctly, that in order to test this I need to:

1. Apply not a default cursor theme (for example Breeze_Snow)
2. Comment a cursorTheme=Breeze_Snow line in ~/.config/kcminput
3. Check that Gtk apps still using Breeze_Snow
4. Log out and then log in again
5. Check that Gtk apps are using breeze_cursors - the default cursors

?

In D25324#563347, @eszlari wrote:

But seems, this only applies to dependencies checked by find_package().

In D25324#562909, @broulik wrote:

I think you would want to make that a RUNTIME dependency.

Rebase on new master

In D24743#562656, @zzag wrote:

Sweet! I wonder whether this KDED module can be used to synchronize the gtk-decoration-layout property with kwin's decoration button layout.

In D24744#562640, @ngraham wrote:

Can you rebase this?