Josselin Mouette <j...@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.pack...@intel.com
pgpmwHwIldT7h.pgp
Description: PGP signature
