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

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

I realise that it was perhaps a tactical error to send both
(a) a message with impassioned rhetoric and (b) a message containing
constructive proposal.

Let me repost the proposal with some extra commentary:

Ian Jackson writes:
> I had an interesting and helpful conversation with a member of the KDE
> team at Debconf.  They made an interesting proposal:
> 
>  * We have machinery that can produce trad menu files from desktop
>    files.
> 
>  * It is possible to have extension information in extra fields in a
>    .desktop file.  This could be used to record the trad Debian
>    category and name metadata currently residing in trad Debian menu
>    files.
> 
>  * Where such metadata is accepted by upstream, we could include it in
>    the primary .desktop file.
> 
>  * Where such metadata is not accepted by upstream, our tooling could
>    be arranged to be able to combine XDG information from two .desktop
>    files, one from upstream and one provided in the Debian package.
>    This would avoid the need for patching an upstream menu file, which
>    is unattractive.
> 
>  * 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.
> 
> 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 ?
> 
>       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.)
> 
>       Whereas most software that ships a .desktop file will have
>       fairly extensive build dependencies, and in general adding image
>       conversion tools to their build dependencies will not be
>       awkward.  This also means the conversion is done once, at
>       package build, rather than on each end-user system.
> 
>       Therefore the format specified in the .deb, to be used by trad
>       menu consumers should continue to be the trad Debian menu file.
> 
>  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.

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.

 - a small amount of work in the already-existing .desktop-to-menu
   conversion program

 - a policy draft explaining what should come out in the .deb, with
   some informative text explaining how to get this effect using only
   .desktop files (or perhaps simply giving references to the
   appropriate tool documentation)

 - policy should probably say that a contributor sending a trad menu
   patch for a program with a .desktop file should do so by sending
   a .desktop file patch, rather than a trad menu patch.

In the longer term:

 - Desktop program maintainers would get occasional patches to add
   trad menu metadata to their .desktop files.  The tooling would then
   do the right thing.  This is the only extra human work that those
   maintainers would have to do.

 - GUI program maintainers have a choice of whether to provide trad
   menu entries via this new mechanism or by providing a separate trad
   menu file.

 - Maintainers of non-GUI programs which don't want to be in the DE
   menus can continue to provide menu entries for the trad menu
   without needing to interact with the XDG menu system.

 - Trad menu consumers do not need to gain any heavyweight runtime
   dependencies.

 - It is still possible to make the trad menu visible in DEs using the
   existing technique.  When that is done there are a trad menu entry,
   and DE menu entry, for the same program, each categorised and
   labelled according to the corresponding menu scheme.

Ian.