[Pkg-kde-extras] Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection

[Boris Pek]

Hi,

Thank you for a reply.

>>   We are talking about replacing the package kcm-gtk by package
>>   kde-gtk-config which has wider functionality.
>  That's debatable.

I can't agree with you: kde-gtk-config has wider functionality objectively.

As I wrote earlier, kcm-gtk does not allow to:
* select themes for Gtk 3.x applications
* preview available themes for Gtk 2.x and Gtk 3.x applications
* custmize toolbars and menus for Gtk applications
* select icon themes for Gtk applications
* download and apply Gtk 2.x and Gtk 3.x themes from http://opendesktop.org/
  in few mouse clicks

All these things can be done in kde-gtk-config.

>>   Wheezy freeze will be soon. And I really believe that this
>>   configuration module should be in it.
>  That's subjective.

There are Gtk 3.x applications in Wheezy. And their look and fill can't be
configured in KDE using current configurations module. Is it subjective?

>  Anyway; I would strongly oppose a duplication of packages with similar
>  functionality: either the existing src:kcm-gtk is enhanced to support
>  the new features or it should be deprecated in favour of a new source
>  package producing a binary package named identically.

Agreed.

But kde-gtk-config already exists and in good shape. Upstream is very friendly.
He accepted my patches and fixed my issues. It was about 40 e-mails between us
during preparing the package. And I don't want to drop this work into trash.

And if you want similar features in kcm-gtk, someone should write them from
scratch. Does it make sense?

>  (A third solution, technically ugly but doable would be to keep the
>  src:kcm-gtk source name but have it's content be the new source's.)

Yep, this is not a variant.

>>   What is the procedure for replacing the binary package by one from
>>   another source package?
>  The only existing procedure is "consensus", reached through discussion.

Ok.

>>   Could I maintain my package outside kde-extras team in this case?
>  This wouldn't make sense.

Ok. Now Debian KDE Extras Team is a maintainer and I am an uploader.

>  So; such a package would make sense if it provides a set of
>  functionalities including _everything_ currently provided by
>  src:kcm-gtk.

kcm-gtk has only 4 functions:
1) Selecting available Gtk 2.x theme.
2) Selecting few paths for searching Gtk 2.x themes in the system.
3) Setting up the same font as in KDE applications.
4) Setting up font manually.

Functions 2) and 3) are not available in kde-gtk-config now. But...

Function 2) has no sense. Because kde-gtk-config allow to install themes from
any local location and from special web site (http://opendesktop.org/).

Function 3) can be added very quickly. But even now it is not very important
because fonts could be set manually.

>  In that case, it shall be named kde-config-gtk-style and
>  get a version bigger than the current 2:0.5.3-1 (such as it's 2.0-1
>  version plus a bigger epoch such as 3:2.0-1).

Done.

>  Then, after some testing,
>  I would be OK to deprecate kcm-gtk (removing the source from unstable).

And what about testing branch of Debian? Will be the package processed
automatically?

>  In order to allow such testing before the Wheezy's release, I think this
>  new kde-gtk-config should be targeted at experimental, to ease upgrading
>  and functionality testing without breaking Wheezy

Done.

>  If such changes are donc, I might consider sponsoring.

Great! Could you look on the package now?

Links:
  http://mentors.debian.net/debian/pool/main/k/kde-gtk-config/kde-gtk-config_2.0-1.dsc
  http://mentors.debian.net/package/kde-gtk-config
  https://github.com/tehnick/kde-gtk-config-debian/tree/master/debian/

Best regards,
Boris