Bug#741573: Two menu systems
Hi,
Le lundi 30 juin 2014 à 13:59 -0700, Keith Packard a écrit :
> One of the arguments that I had heard expressed against supporting
> applications shipping .desktop files is that it would reduce the number
> of applications offered in existing menu packages; I'm hoping that my
> draft addresses this question by demonstrating that the .desktop format
> offers a proper superset of the information found in menu files, and
> that package maintainers could mechanically convert their existing menu
> files into .desktop files without loss of information.
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.
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'm afraid that my notion of a transition plan was expressed implicitly
> in the proposal rather than explicitly. In any case, the transition plan
> I had in mind was pretty simple:
>
> 1. Implement .desktop parsing support in the existing 'menu' package so
> that packages providing only .desktop files would be incorporated
> into menu programs without further change.
That part of the plan is obvious: replace the current “menu” package by
https://wiki.archlinux.org/index.php/Xdg-menu
> 2. Transition packages from providing menu files to providing .desktop
> files, deprecating support for the menu file format within the
> archive over time.
[snip]
> I'd love to see so many programs in my menu that menu program developers
> are encouraged to figure out how to reasonably select entries in menus
> so that we can get to some kind of intentional preferential listing
> mechanism, rather than the ad-hoc selection that we have today.
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.
> However, I don't think that Policy is a sound place to make user
> interface design decisions, and that we should naturally defer how to
> present the provided application set to the menu program developers. I
> believe this part of Policy should focus on stating what application
> developers are expected to provide for the menu system, and then let the
> menu program do 'something sensible' with the provided data.
Agreed.
[snip]
> I think this distinction is entirely an artifact of the current split
> between packages, some of which install only a menu file, and some of
> which install both menu and .desktop files. I would hope that by
> encouraging all packages to deliver only .desktop files, we'll see
> developers thinking about sensible ways to present hundreds of
> applications to their users.
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.
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Reply to: