[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#741573: Two menu systems

Josselin Mouette <joss@debian.org> writes:

> One of the problems I have with your proposal, compared to Charles’
> original patch, is that it encourages maintainers of hundreds of (IMHO
> useless) menu files to port them to the desktop format.

Yeah, there are a lot of inappropriate entries in my /usr/share/menu
directory. Can we fix policy to weed these out? The current
wording in §9.6:

      All packages that provide applications that need not be passed any
      special command line arguments for normal operations should
      register a menu entry for those applications.

seems problematic to me -- it seems to require menu entries for things
as diverse as a web browser and a python interpreter. Coming up with
wording that encourages only programs which are conventionally used in
interactive mode to be included seems like a good fix here.

> We don’t need menu entries for bc or python, unless they are
> NoDisplay=true. This should be obvious, but currently we have trad menu
> entries for them. The proposed wording for the policy (which is the
> result of a compromise work between desktop maintainers and policy
> editors) handles this by stating maintainers must set appropriate
> NoDisplay/OnlyShowIn/NotShowIn fields, but experience shows maintainers
> are not cooperative in this matter (hence gross hacks such as
> gnome-menus-blacklist).

I think it's a lack of clarity in the spec which encourages
over-production of menu entries.

> Experience shows it doesn’t work. You can have ad-hoc selection after
> time (either automatic or manual), but you need something that works out
> of the box. Three-level nested menus with hundreds of entries are not
> something to present a new user, regardless of her proficiency.

I completely agree, but I don't think we can mandate good UI design in
Policy, all we can do is provide the tools necessary to construct a good

> There is a sensible way: not present the useless ones. Use
> NoDisplay=true everywhere appropriate.
> I don’t think presenting the whole contents of /usr/bin in a menu is
> helpful in any way to anyone.

As you say, we can't expect package developers to always make the
choices we'd like. I don't have any good solutions here, but I don't
think how the underlying menu information is transmitted in the package
is affected by that problem.


Attachment: pgp0WziylD8HN.pgp
Description: PGP signature

Reply to: