Bug#573865: menus.blacklist faar to long

Sat Apr 23 14:36:08 UTC 2011

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/23/2011 02:44 AM, Josselin Mouette wrote:
> Le samedi 23 avril 2011 à 01:41 +0200, Florian Uekermann a écrit : 
>> I tried gnome 3 today and spend way too much time figuring out why so
>> much applications I need do not show up.
> 
> I don’t know whether you’re talking of gnome-shell or gnome-panel, but
> there are additional issues with the gnome-shell menus that are still to
> be fixed.
> 
I installed both and the gnome-session package... ...and a bunch of
other stuff matching the version number. I noticed the issue in the list
of programs you get after moving the mouse in the upper-left corner and
clicking on Applications. I guess thats the gnome-shell menu. Well I
noticed the issue with multiple entries for some applications to, but it
didn't bother me much since you there is plenty of space in full-screen
and the search function is faster anyway than scrolling through the
menu... ...thats a design which really motivates me to use gnome more
often (I am a heavy kde user since version 4)

>> I really need the following applications every day regardless of the
>> desktop environment I'm using:
>>
>> kate - There is no replacement for kate I happen to know apart from some
>> developement environments. Seriously, there are people who really need
>> kate and some of them use gnome.
>>
>> kopete - My favorite client. Whats wrong with it.
>>
>> k3b
>>
>> okular
>>
>> gwenview
> 
> You can fire the menu editor (typically alacarte) and enable them.
> 

Please remove at least kate, kopete and k3b from the blacklist. A
kde-standard install doesn't install those and at least kate and k3b are
not just basic stuff like a viewer or something. Blocking kate is like
blocking emacs. It doesn't hurt those few who don't need it and have it
installed for some reason to have 1 more entry in 3 sections and it will
save a lot of people from getting scared when trying gnome.

>> There are lots of other applications that are blocked for no good
>> reason. But I don't really need most of them, so I don't care, other
>> people might...
>>
>> kwrite - It is a nice editor and by no means kde specific software. Not
>> blocking it doesn't hurt anybody.
>>
>> all kdegames - kde-standard doesn't depend on this. Someone installed
>> them on purpose if they are present, thats kind of cruel ;).
>>
>> konsole - You are not blocking xterm, why konsole? It's a nice application.
> 
> You can empty /etc/gnome/menus.blacklist if you want to disable that.
> Have fun with your menu that goes beyond the screen height, however.
> 
>> This is not Ubuntu, I am not aware of some kind of "Only one app for a
>> specific purpose"-policy in Debian.
> 
> There’s no “10 apps for the same purpose” policy either. So far the only
> application duplication that we have on the default GNOME install is
> iceweasel/epiphany, and it is forced upon us by the d-i maintainers.
> 
>> It might be a good idea to contact the maintainers of those files that
>> should really be blocked and aks them to hide them in gnome (or
>> everywhere) and gradually remove the entries of the whole list.
> 
> This has of course been requested before implementing something as idiot
> as a blacklist - after all we already have OnlyShowIn / NotShowIn for
> that purpose.
> 
> Now, I somehow agree that if you just run “apt-get install k3b”, you
> should see it in the GNOME menus. However if you install kde-full (and
> it is enough that two users of the same system want a different DE), you
> will obtain an unusable menu (and I really mean unusable, I didn’t came
> up with the blacklist idea because of 3 spurious applications). I don’t
> have a magical recipe to handle correctly both cases, still.
>
> If you have ideas to improve the situation without too much
> complication, I’m open to them. But all in all, I’m more interested in
> improving the GNOME user experience as a whole (and that means improving
> e.g. brasero) than in getting it to work with k3b.
>
> Cheers,

I'm not asking to remove the blacklist and add everything back to the
gnome menus. I agree with you that the resulting mess wouldn't be
acceptable. But I think some corrections are necessary and I volunteer
for the resulting work. There are two major tasks that should be done:

Task one: (important, short term and long term)

The the kde task (installed on setup or using tasksel) installs mainly
k3b, xterm, network-manager-kde, the stuff from kde-standard and some
things that aren't in the blacklist for a good reason like openoffice
and iceweasel or don't provide a .desktop file anyway. They should be
sorted into four categories:

- -Applications providing a basic functionality every DE implements
without any real differences. They obviously shouldn't appear in the
gnome menu. Examples are: konsole, xterm, network-manager-kde,
dragonplayer, kmix, ksnapshot, dolphin etc.

- -Applications providing functionality that is not basic-DE
functionality. For Example: kate, openoffice, iceweasel.
Those should appear in the gnome menu.

- -Applications which don't make any sense in any other DE, for example
the various DE-specific system-settings applications and kde-accessibility.

- -Applications that provide a functionality which is missing in gnome
even though the goal is to provide a gnome version. They should
definitely appear in gnome until a substitute is available. If they
belong to the first or second category can be decided later, it doesn't
exactly matter now. (I think this last one is particularly important,
since this is about providing the best user experience, not to prove
that every group of developers is capable of providing a specific kind
of application.)

Task two: (most important to get a long term solution)

The package maintainers of the packages still in the blacklist should be
contacted and a more general solution should be found, eg. Add
OnlyShowIn, NotShowIn, complete removal of .desktop file (seriously...
...who needs 7 top level java menu entries, I doubt that I will ever use
a single one of them), or exclusion from meta-packages. I think the
latter could be important for a clean solution a main reason for this
mess seems to be that stupid kde package which installs about everything
which is somehow related to KDE. Fortunately they got rid of it (kde is
a transitional package (lenny to squeeze) atm) and introduced kde-full
instead (whos description clearly states, that it contains about
everything... ...those who install it asked for the mess, and they get
it independently from the DE).

As mentioned above, I would like to do that on a per application basis
until every issue solved or I get bored with it. In case you are happy
with this roadmap and with me doing the mentioned stuff, what would the
appropriate procedure be, filing a bug for every change or simply
reporting progress in this thread and requesting the appropriate changes
in the blacklist. Of course this is not only about improving the gnome
menu, it might be usefull take a look on this in some gnome programs too.

Best regards,
Florian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2y47sACgkQfrgUVjQ9SUfFuQCeKmzEWVzVTtJMqVZY375ZYIMM
sXcAnAgtGAbU33STNtgOs/g0HU8uC0+j
=WT82
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x343D4947.asc
Type: application/pgp-keys
Size: 2394 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20110423/7ac724e8/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x343D4947.asc.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20110423/7ac724e8/attachment-0001.obj>