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