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

Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote:
> 9.6. Menus
> ----------

>      Two menu systems are used in Debian: the _FreeDesktop menu_ and the
>  1   _Debian menu system_.  Packages shipping applications that belong to
>      one or both menu systems should provide the necessary entry files to
>      integrate with them.

I don't think this is off to a particularly good start.  The purpose of
Policy is to provide maintainers with concrete guidance about how to
integrate with the rest of the system.  Telling maintainers "there are these
two systems and you can integrate with either of them as appropriate" is not
really providing much guidance.  It doesn't tell maintainers how to
determine which menu system their package belongs to, and it doesn't tell
maintainers of packages that want to consume a menu which one they should

Furthermore, I think the idea of an application "belonging" to one system or
the other is misplaced.  The purpose of both the original menu system and
the freedesktop standard is to give users consistent, menu-driven access to
the software installed on the computer.  While a given desktop environment
is going to give precedence to software that is integrated with that desktop
environment, users should be able to expect that they can access all
software installed on the system through the GUI, via the appropriate
submenus.  Telling maintainers to integrate with one of two different menu
systems does not achieve this.

So if the Debian menu system is insufficiently expressive to meet our needs,
we should be giving clear advice for the use of the fdo menu system.

>         * 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 ingrate well with the default icon themes.  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.

As a first cut this seems ok, but I would prefer to see more concrete
guidance recorded in policy about what values of NotShowIn/OnlyShowIn should
be used and when.

> 9.7. Multimedia handlers
> ------------------------

>      Media types (formerly known as MIME types, Multipurpose Internet Mail
>  3   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.

>      Packages which provide programs to view/show/play, compose, edit or
>      print media types should register them using either the _FreeDesktop_
>      system or the _mailcap_ system.

Again, I do not believe an either/or recommendation is appropriate here. 
This is abdicating the responsibility of Policy to provide concrete advice
to maintainers.

I believe we are at the point that we should be recommending a preference
for the fdo MIME interfaces, together with appropriate transition handling
to ensure proper integration with mime-support.  It's possible that the
transition is already handled transparently by the mime-support package and
its triggers, such that no additional dependencies need to be added anywhere
(since /etc/mailcap is already owned by mime-support, clearly any package
which is consuming it should already be depending on it).  In that case, no
additional policy language is needed, other than to make it clear which of
these two interfaces we are recommending that maintainers use.

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: