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 UI. > 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. -- keith.packard@intel.com
Attachment:
pgp0WziylD8HN.pgp
Description: PGP signature