I can only speak for myself here, but to be honest, I don't think we want this one in Fedora. We have kcm-gtk and xsettings-kde set up to handle these settings, adding a new KCM for them would just conflict with the existing setup.

kcm-gtk is unable to find and use locally installed themes (~/.themes/*), and it ignores any gtk3 stuff generally. That's why I prefer kde-gtk-config.

The problem with kde-gtk-config is that it tries to let you configure some settings which are already handled by xsettings-kde (usually by making the GTK+ settings automatically match the KDE ones, which IMHO is the best solution wherever it's possible), so if xsettings-kde is running, which it is by default, the settings you make in kde-gtk-config will have no effect. Thus, to the user, it will look like the application does not work.

As for the GTK+ 2 vs. 3 theming, we enforce matching GTK+ 2 and 3 themes through xsettings-kde (it reads the GTK+ 2 theme setting from kcm-gtk and tries to enforce that over XSettings for both GTK+ 2 and 3) because of the braindead way GTK+ 3 settings work (and our requests for improvements having been totally ignored by the GTK+ maintainers):
* GTK+ 3 only reads settings from a hardcoded config file. It does not take environment variables for additional config files as GTK+ 2 did. So it is not possible to set a GTK+ 3 theme only for KDE Plasma sessions (which is what we want; the settings you make in KDE System Settings should not affect other desktops) except through XSettings.
* XSettings handling is also very stupid because both GTK+ 2 and 3 use the same NET/ThemeName XSetting for the theme. (GNOME does not see this as a problem because they have always been enforcing matching themes, as braindead as that is.)
There's some discussion of these issues in Bugzilla, in meeting logs and/or mailing list archives etc. The result of this is that, with xsettings-kde running (and again, that's the default), you'll end up with either only the GTK+ 2 theme setting being applied, or both being ignored, depending on how kde-gtk-config saves the setting.

(In reply to comment #3)
> The problem with kde-gtk-config is that it tries to let you configure some
> settings which are already handled by xsettings-kde (usually by making the
> GTK+ settings automatically match the KDE ones, which IMHO is the best
> solution wherever it's possible), so if xsettings-kde is running, which it
> is by default, the settings you make in kde-gtk-config will have no effect.
> Thus, to the user, it will look like the application does not work.
> 
I know about that and I have disabled xsettings-kde temporarily.

> As for the GTK+ 2 vs. 3 theming, we enforce matching GTK+ 2 and 3 themes
> through xsettings-kde (it reads the GTK+ 2 theme setting from kcm-gtk and
> tries to enforce that over XSettings for both GTK+ 2 and 3) because of the
> braindead way GTK+ 3 settings work (and our requests for improvements having
> been totally ignored by the GTK+ maintainers):
Doesn't matter, I don't think that users need different settings for Gtk2 and Gtk3. Actually I could live in harmony with kcm-gtk if it wouldn't ignore custom Gtk themes in ~/.themes. The popup window in the control center (search path configuration) says something about engines in custom locations, and when I submit  ~/.themes as an additional folder, nothing happens.

However, I set this review request to NotReady. Instead continue working on it, I will file a bug against kcm-gtk. Perhaps we'll find a solution to use custom Gtk themes. If yes, kde-gtk-settings becomes superfluous and this review request can be closed.

I'm no longer interested to maintain this package. Closing it as FE-DEADREVIEW.