Bug#707851: debian-policy: soften the wording recommending menu files
Hi,
Le dimanche 12 mai 2013 à 10:08 +0900, Charles Plessy a écrit :
> If we were to recommend FreeDesktop menu entries instead of Debian menu
> entires, and if this recommendation were followed carefully, this would
> increase the number of entries in the Gnome and KDE menus on some sytems where
> the user has installed extra packages. In particular, some entries will
> be redundant with the default applications, and provide only an XPM icon or
> no icon at all.
>
> One way to avoid this is to use HideIn keys, but this requires coordination
> between the maintainers of the package providing menu entries, and the teams
> maintaining Desktop environments. If there is already an unwritten norm about
> this, then it would be the good time to add it to the Policy: regardless in
> which package the menu entry file is, who has the final word on which menu
> actually displays the entry.
Currently, the final word on the menus layout is in the hands of the
menu implementations’ maintainers. However, some maintainers being
uncooperative about menu categories or OnlyShowIn/NotShowIn lead us to
implement a blacklist mechanism in gnome-menus.
Maybe the wording should encourage maintainers to be careful before
providing menu entries that don’t serve any purpose at all. There is
nothing wrong per se with menu entries for text programs, for example,
but if practically speaking, users won’t use them outside already
launched terminals, it doesn’t make any sense to ship them.
> It looks to me that the scope of the Debian menu system is broader than
> the FreeDesktop system, so in line with the previous discussions about
> the overlap between both, I think that the best way forward would be to
> recommend to declare an entry in one system, but not both.
I don’t think the basic purpose is different. It’s just that so far, the
Debian menu maintainers have put menu completeness before usability. We
should use the opportunity of a policy change to take care of that.
You are also right about MIME handling; now that you have updated
mime-support in unstable (thanks!). As such, let me propose an alternate
wording.
9.6 Menus
Packages shipping applications that belong in the menu of a
desktop environment should provide desktop files for integrating
with the menus, following the Desktop Menu Specification
available at
http://standards.freedesktop.org/desktop-entry-spec/latest/
However, the maintainer should remind that the menu is often the
primary interface for the user, and as such it should be filled
with what is most useful to her. Therefore :
* If the application will only be used directly in rare
cases – mostly called from a terminal, or used solely as
handler for a given MIME type, for example – the desktop
entry should include the NoDisplay=true stanza, so that
it can be configured to be displayed only by those who
need it.
* Unless hidden by default, the desktop entry MUST point
to a PNG or SVG icon with a transparent background,
providing at least the 22×22 size, and preferably up to
64×64. The icon should be neutral enough to ingrate well
with the default icon themes.
* The maintainer should coordinate with the maintainers of
the menu implementations, in order to avoid bad
interactions with other wrong categories or icon
duplication. Especially for packages installed by
default, the contents of the NotShowIn/OnlyShowIn
stanzas should be validated by the maintainers of the
relevant environments.
Packages can, to be compatible with Debian additions to some
legacy window managers, also provide a menu file.
9.7 Multimedia handlers
Packages shipping applications able to view, edit or point to
files of a given MIME type (e.g. audio/x-mp3 or text/plain),
and/or open links with a given URI scheme, should provide
desktop files as described in §9.6, and using the MimeType
stanza. For URI schemes, the relevant MIME types are
x-scheme-handler/* (e.g. x-scheme-handler/https).
The list of supported MIME types, as well as the corresponding
file magic and filename extensions, is provided by the
“shared-mime-info” package. If an application needs to support a
new MIME type, the maintainer should request its addition to
shared-mime-info first, to the Debian or upstream freedesktop
maintainers.
Until its addition to “shared-mime-info”, the package can ship a
MIME file as described in the Shared MIME-info specification:
http://standards.freedesktop.org/shared-mime-info-spec/latest/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
Reply to: