Bug#707851: debian-policy: soften the wording recommending menu files
In general, seconded. Thank you for writing this up! The following are
mostly editing notes intended for whoever (possibly myself if I can find
time) might turn this into SGML.
Josselin Mouette <joss@debian.org> writes:
> 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
s/remind/remember/
> primary interface for the user, and as such it should be filled
> with what is most useful to her. Therefore :
I'm not sure if we have a consistent style on gendered pronouns. I
personally always use singular they, and I vaguely recall that reaching
some degree of consensus in a previous discussion.
> * If the menu entry is not useful in the general case as a
> standalone application, 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. It is encouraged to ship
> the icon in the default “hicolor” icon theme
> directories, or to use an existing icon from the default
> theme.
s/default/"hicolor" right at the end of the sentence, just to be clear
that hicolor is the one to use, rather than sending people down the path
of trying to figure out how to have the icon change if the default ever
changes. (People who don't do this a lot, like myself, tend to get
trapped in unnecessary investigations like that. :))
> * The maintainer should use the “debian-desktop” mailing
> list too coordinate with maintainers of menu
s/too/to/
> implementations, in order to avoid bad interactions with
no comma, "in order to avoid problems with categories or bad interactions
with other icons."
> other icons or wrong categories. Especially for packages
> which are part of installation tasks, 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. Such menu
> entries should follow the Debian menu policy, which can be found
> in the menu-policy files in the debian-policy package. It is
> also available from the Debian web mirrors
> at /doc/packaging-manuals/menu-policy/.
> 9.7 Multimedia handlers
> MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049) is
> a mechanism for encoding files and data streams and providing
> meta-information about them, in particular their type and format
> (e.g. image/png, text/html, audio/x-mp3).
>
> Registration of MIME type handlers allows programs like mail
> user agents, file managers and web browsers to invoke these
> handlers to view, edit or display MIME types they don't support
> directly.
>
> Packages shipping applications able to view, edit or point to
> files of a given MIME type, 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
s/, and using the/ that include a/. s/stanza/entry/ (following the
terminology of the desktop standard).
> 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 in XML format as described in the Shared MIME-info
> specification:
> http://standards.freedesktop.org/shared-mime-info-spec/latest/
I'll leave it to Charles to make the call on whether to keep the old
language about mailcap entries for right now.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: