Bug#707851: Let's remove the Debian menu from the Debian Policy ?
Charles Plessy
plessy at debian.org
Sat Jan 11 02:46:10 UTC 2014
Hello everybody,
I have read a lot of scepticism about the Debian menu in this thread, and no
actual support for it. Perhaps I was trying to be too consensual and proposed
an over-complicated solution while it is clear that the FreeDesktop system is
superior.
I attached a new patch, where the Debian menu is removed, and pasted below a
text export of the 9.6 and 9.7 sections after application of the patch.
Note that for the media types, there is some homework to do before recommending
to replace all mailcap entries by desktop entries (with NoDisplay=true for
command-line programs), so I am not proposing this for the moment (and welcome
help with the “mime-support” package).
I welcome your comments, but I am not calling for seconds (this is not a vote).
Please if you make objections, indicate what are your stakes regarding the menu
(user ? developer ? provider of entries ? etc.).
9.6. Menus
----------
Packages shipping applications that comply with minimal requirements
described below for integration with desktop environments should
register these applications in the desktop menu, following the
_FreeDesktop_ standard, using text files called _desktop entries_.
Their format is described in the _Desktop Entry Specification_ at
http://standards.freedesktop.org/desktop-entry-spec/latest/ and
complementary information can be found in the _Desktop Menu
Specification_ at http://standards.freedesktop.org/menu-spec/latest/.
The desktop entry files are installed by the packages in the directory
`/usr/share/applications' and the FreeDesktop menus are refreshed
using _dpkg triggers_. It is therefore not necessary to depend on
packages providing FreeDesktop menu systems.
Entries displayed in the FreeDesktop menu should conform to the
following minima for relevance and visual integration.
* Unless hidden by default, the desktop entry must point to a PNG
or SVG icon with a transparent background, providing at least the
22x22 size, and preferably up to 64x64. The icon should be
neutral enough to integrate 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 _hicolor_
theme.
* If the menu entry is not useful in the general case as a
standalone application, the desktop entry should set the
`NoDisplay' key to <true>, so that it can be configured to be
displayed only by those who need it.
* In doubt, the package maintainer should coordinate with the
maintainers of menu implementations through the _debian-desktop_
mailing list in order to avoid problems with categories or bad
interactions with other icons. Especially for packages which are
part of installation tasks, the contents of the
`NotShowIn'/`OnlyShowIn' keys should be validated by the
maintainers of the relevant environments.
Since the FreeDesktop menu is a cross-distribution standard, the
desktop entries written for Debian should be forwarded upstream, where
they will benefit to other users and are more likely to receive extra
contributions such as translations.
9.7. Multimedia handlers
------------------------
Media types (formerly known as MIME types, 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/ogg').
Registration of media type handlers allows programs like mail user
agents and web browsers to invoke these handlers to view, edit or
display media types they don't support directly.
There are two overlaping systems to associate media types to programs
which can handle them. The _mailcap_ system is found on a large
number of Unix systems. The _FreeDesktop_ system is aimed at Desktop
environments. In Debian, FreeDesktop entries are automatically
translated in mailcap entries, therefore packages already using
desktop entries should not use the mailcap system directly.
9.7.1. Registration of media type handlers with desktop entries
---------------------------------------------------------------
Packages shipping an application able to view, edit or point to files
of a given media type, or open links with a given URI scheme, should
list it in the `MimeType' key of the application's desktop entry. For
URI schemes, the relevant MIME types are `x-scheme-handler/*' (e.g.
`x-scheme-handler/https').
9.7.2. Registration of media type handlers with mailcap entries
---------------------------------------------------------------
Packages that are not using desktop entries for registration should
install a file in mailcap(5) format (RFC 1524) in the directory
`/usr/lib/mime/packages/'. The file name should be the binary
package's name.
The `mime-support' package provides the `update-mime' program, which
integrates these registrations in the `/etc/mailcap' file, using dpkg
triggers[1].
Packages installing desktop entries should not install mailcap entries
for the same program, because the `mime-support' package already reads
desktop entries.
Packages using these facilities _should not_ depend on, recommend, or
suggest `mime-support'.
[1] Creating, modifying or removing a file in `/usr/lib/mime/packages/'
using maintainer scripts will not activate the trigger. In that case,
it can be done by calling `dpkg-trigger --no-await
/usr/lib/mime/packages' from the maintainer script after creating,
modifying, or removing the file.
9.7.3. Providing media types to files
-------------------------------------
The media type of a file is discovered by inspecting the file's
extension or its magic(5) pattern, and interrogating a database
associating them with media types.
To support new associations between media types and files, their
characteristic file extensions and magic patterns should be registered
to the IANA (Internet Assigned Numbers Authority). See
http://www.iana.org/assignments/media-types and RFC 6838 for details.
This information will then propagate to the systems discovering file
media types in Debian, provided by the `shared-mime-info',
`mime-support' and `file' packages. If registration and propagation
can not be waited for, support can be asked to the maintainers of the
packages mentioned above.
For files that are produced and read by a single application, it is
also possible to declare this association to the _Shared MIME Info_
system by installing in the directory `/usr/share/mime/packages' a
file in the XML format specified at
http://standards.freedesktop.org/shared-mime-info-spec/latest/.
Have a nice week-end,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
More information about the pkg-gnome-maintainers
mailing list