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

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

>  * Overall, this would make it possible, therefore, to maintain the
>    menu information primarily in the more sophisticated .desktop
>    format, so that source packages with .desktop files would not need
>    to contain trad menu files too.

Yes, the wording that Sam and I worked out this morning for the final
ballot option advises this kind of solution, where users of the debian
menu system gain access to applications through a combination of menu
and .desktop files.

You can see that draft ballot here:


> The only remaining questions are then :
>  Q1.  Whether it is better to convert from .desktop files to trad
>       Debian menu files at package build time, or to change the
>       existing trad menu consumers to be able to convert .desktop
>       files to the required format ?

I believe that having the debian menu package capable of parsing both
formats will reduce the maintenance burden for packages providing
.desktop files. Someone needs to write a conversion script; adding that
to only the menu package and not all application packages seems like
less work overall.

>       There is an easy answer to this: this conversion may involve
>       image conversion libraries including even perhaps an SVG
>       renderer, and other conversion software, which is
>       disproportionately heavyweight for many trad menu consumers.
>       (Trad menu consumers tend to be non-desktop `lightweight' window
>       managers.)

librsvg2-bin and netpbm are what I use for this work; the dependency
list for these is fairly small, and shares almost everything with
requirements to run a fairly basic X desktop. I do not see this as an
excessive burden to run when installing a new package.

>  Q2.  Whether packages (bc, many command line games, ...) which only
>       want to provide a trad Debian menu entry should do so by
>       including a .desktop file in the source code, or a trad menu
>       entry.
>       I see no need for policy to mandate any particular answer to
>       this.  The maintainer should do what they prefer.

The biggest policy change I've proposed is to remove the requirement for
menu files for any package in the archive, and to replace that with a
fairly soft requirement that "desktop applications" have an associated
.desktop file. Otherwise, maintainers are free to do as they like.

> I think this would involve:
>  - defining new field names for .desktop files to contain
>    the trad menu metadata, as necessary.  I think we can safely
>    call these fields X-Debian-* or X-Debian-Menu-* or something.

I'd like to suggest that all of this additional menu-package specific
information could be delivered with the menu package itself, and not
spread across all of the application packages. As you note, the bulk of
the information loss in translating .desktop to menu files is in the
hierarchy of the debian menu, and not in information tightly tied to the
specific package version, so the information is unlikely to go stale as
things change. By providing some reasonable defaults for Freedesktop
Desktop Menu categories, the need for per-package definitions would be
greatly reduced.

Yes, this seems a bit backwards, but consider the benefits to menu
system users -- it's probably far easier to convince the menu package
maintainers to release a new version that adjusts the location of a new
application within the debian menu system than to get that application
maintainer to package changes which they are reasonably unlikely to be
dependent on.

And, as the hierarchy is defined by the menu system maintainers, it will
likely be more consistent and correct than having the menu
constructed in distributed fashion by a collection of menu system users
and random desktop application maintainers.


Attachment: signature.asc
Description: PGP signature

Reply to: