Bug#707851: debian-policy: soften the wording recommending menu files
Josselin Mouette <joss@debian.org> writes:
> 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.
This looks like the right idea to me.
> 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.
This looks mostly right to me. I always found the inclusion of some
things (dc, for example, or every shell on the system) in the Debian menu
to be rather dubious, and likely to eat up a lot of menu real estate on a
system with a full set of user packages installed.
I'm not sure that "mostly called from the terminal" is quite the right way
of phrasing the point, but I'm not sure what the right way of handling it
is. My feeling is that things that make sense as applications (irssi,
top) should be included in the menu, but things that are really just
command-line utilities (other shells, telnet these days) probably
shouldn't. I'm not sure where ncftp, for example, falls in that list, but
I think both units and bc would ideally appear in the menu.
> * 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.
This is a relatively high bar if the icon has to be custom for that
application, since most maintainers aren't going to have the skills to
make icons. Is it okay to just pick some reasonable icon from, say, the
highcolor set?
> * The maintainer should coordinate with the maintainers of
> the menu implementations, in order to avoid bad
> interactions with other wrong categories or icon
> duplication.
If we're going to make this a should, I think we need to provide some sort
of means for the maintainer to do that. I personally have no idea how I
would go about doing that coordination. (It's not immediately apparent,
from outside the desktop world, that by "maintainers of menu
implementations" you mean "maintainers of software that use desktop files
to present menus.")
> Especially for packages installed by default, the contents
> of the NotShowIn/OnlyShowIn stanzas should be validated by
> the maintainers of the relevant environments.
Yes, this definitely makes sense.
> Packages can, to be compatible with Debian additions to some
> legacy window managers, also provide a menu file.
I think we need to include more of the existing verbiage, at least
including the pointer to the current menu specification. (It's still
required, so far as I know, for menu support in fvwm, which is still
fairly widely used among old-school folks like myself.)
> 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/
This looks great as an addition to that section. I think we should keep
the current background information (the definition of MIME and the
discussion of what it's used for), though, and at least for right now we
should probably also keep the mailcap instructions, since I'm fairly sure
they're still used by very widely used programs like mutt and the Emacs
mail clients.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: