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

Bug#707851: debian-policy: soften the wording recommending menu files



Le Sat, May 11, 2013 at 10:48:47PM +0200, Sune Vuorela a écrit :
>        <sect id="menus">
>         <heading>Menus</heading>
>  
> -       <p>
> -         The Debian <tt>menu</tt> package provides a standard
> -         interface between packages providing applications and
> -         <em>menu programs</em> (either X window managers or
> -         text-based menu programs such as <prgn>pdmenu</prgn>).
> +       <p>Applications that belongs in the menu of a desktop environment
> +         or a window manager should provide desktop files for integrating
> +         with the menus.
>         </p>
>  
> -       <p>
> -         All packages that provide applications that need not be
> -         passed any special command line arguments for normal
> -         operation should register a menu entry for those
> -         applications, so that users of the <tt>menu</tt> package
> -         will automatically get menu entries in their window
> -         managers, as well in shells like <tt>pdmenu</tt>.
> +       <p>For desktop files, see the Desktop Menu Specification available at
> +         <tt><url name="http://standards.freedesktop.org/menu-spec/latest/"; 
> +                id="http://standards.freedesktop.org/menu-spec/latest/"/></tt>
> +       </p>
> +
> +       <p>Packages can, to be compatible with legacy debian additions
> +         to some legacy window managers, provide a menu file.
>         </p>

Dear Sune,

thank you for raising the issue.

I would like to clarify one point with you and Michael.

If we were to recommend FreeDesktop menu entries instead of Debian menu
entires, and if this recommendation were followed carefully, this would
increase the number of entries in the Gnome and KDE menus on some sytems where
the user has installed extra packages.  In particular, some entries will
be redundant with the default applications, and provide only an XPM icon or
no icon at all.

One way to avoid this is to use HideIn keys, but this requires coordination
between the maintainers of the package providing menu entries, and the teams
maintaining Desktop environments.  If there is already an unwritten norm about
this, then it would be the good time to add it to the Policy: regardless in
which package the menu entry file is, who has the final word on which menu
actually displays the entry.

It looks to me that the scope of the Debian menu system is broader than
the FreeDesktop system, so in line with the previous discussions about
the overlap between both, I think that the best way forward would be to
recommend to declare an entry in one system, but not both.  For the
Debian menu system, this would require to add the capacity to read the
FreeDesktop entries in addition to the Debian menu entries.  As noted
by Sune, some package maintainers have anyway decided already to stop
shipping Debian menu entries.

    http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

About the current patch, I think that the mention of "legacy debian additions
to some legacy window managers" is not informative as it does not provide
guidance.  For the both menu systems, I would like to have explanations about
1) what is the scope of this menu, 2) what is the standard syntax for the
entries, and 3) how packages should implement this.

For the FreeDesktop entries, can you summarise the expectations, in particular
about the scope and whether it is better to have a FreeDestkop entry with an
awful or missing icon or no entry at all ?  This could be the basis for a
section 9.6.1, while the current part about the Debian menu would be 9.6.2.

Lastly, the FreeDesktop entry files have also associate programs with media
types, and as you probably noticed, this is in the scope of section 9.7
(Multimedia handlers), so please let us know your thougts or suggestions (maye
in a separate bug ?).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


Reply to: