Le dimanche 12 mai 2013 à 16:06 -0700, Russ Allbery a écrit :
> Josselin Mouette <j...@debian.org> writes:
> > How about simply “not useful as a standalone application”?
>
> That sounds great to me.
Here is a new proposed wording with all your suggestions.
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 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.
* The maintainer should use the “debian-desktop” mailing
list too coordinate with maintainers of menu
implementations, in order to avoid bad interactions with
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
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/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1368432170.13176.41.camel@tomoyo
