[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#707851: Let's remove the Debian menu from the Debian Policy ?



Hi peoples

<fullquote at bottom>

I have the impression that most people seems to agree on something like this. 
I think I might even stretch it and call it a 'rough consensus' with a couple 
of people in the rough end of it.

Can we please move it forward?

Thanks

Sune

On Saturday 11 January 2014 11:46:10 Charles Plessy wrote:
> 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,

-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank


Reply to: