Bug#741573: Two menu systems
Le Fri, Jun 27, 2014 at 04:59:50AM -0700, Cameron Norman a écrit :
>
> I believe the major aspect of .desktop files that makes them harder is the
> icon handling. Perhaps debian policy should instruct that a certain icon
> size must always be available in a particular format (e.g. 32x32 png) so
> that WMs do not have to handle so many corner cases in that area.
Hi Cameron,
When working on #707851, I made sure that this is addressed with the input of
Debian maintainers of desktop environments using the FreeDesktop menu.
http://anonscm.debian.org/gitweb/?p=dbnpolicy/policy.git;a=commitdiff;h=ba679bff76f5b9152f43d5bc901b9b3aad257479;hp=f6997b3ba7
93c9a9e463cca9f7e7b138add8b788
Here is the relevant extract.
+ Entries displayed in the FreeDesktop menu should conform to the
+ following minima for relevance and visual integration.
+
+ <list>
+ <item>
+ Unless hidden by default, the desktop entry must point to a PNG
+ or SVG icon with a transparent background, providing at least
+ the 22×22 size, and preferably up to 64×64. The icon
+ should be neutral enough to integrate well with the default icon
+ themes. It is encouraged to ship the icon in the default
+ <em>hicolor</em> icon theme directories, or to use an existing
+ icon from the <em>hicolor</em> theme.
+ </item>
+
+ <item>
+ If the menu entry is not useful in the general case as a
+ standalone application, the desktop entry should set the
+ <tt>NoDisplay</tt> key to <var>true</var>, so that it can be
+ configured to be displayed only by those who need it.
+ </item>
+
+ <item>
+ In doubt, the package maintainer should coordinate with the
+ maintainers of menu implementations through the
+ <em>debian-desktop</em> 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 <tt>NotShowIn</tt>/<tt>OnlyShowIn</tt> keys should be
+ validated by the maintainers of the relevant environments.
+ </item>
+ </list>
I beleive that this part is non-controversial. The controversy is whether we
should still require with the strenght of a "should" in the Policy that
packages have to contain a Debian Menu entry, ignoring the fact that a) a lot
of packages have already not respected this point for years, if not decades,
and b) the Debian Menu is not anymore part of standard installations in Jessie.
That is: this part of the patch (reformatted by hand for easier reading).
<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>
<p>
- The menu policy can be found in the <tt>menu-policy</tt>
- files in the <tt>debian-policy</tt> package.
- It is also available from the Debian web mirrors at
- <tt><url name="/doc/packaging-manuals/menu-policy/"
- id="http://www.debian.org/doc/packaging-manuals/menu-policy/";></tt>.
</p>
- <p>
- Please also refer to the <em>Debian Menu System</em>
- documentation that comes with the <package>menu</package>
- package for information about how to register your
- applications.
+ <p>
+ Packages can, to be compatible with Debian additions to some window
+ managers that do not support the FreeDesktop standard, also provide a
+ <em>Debian menu</em> file, following the <em>Debian menu policy</em>,
+ which can be found in the <tt>menu-policy</tt> files in the
+ <tt>debian-policy</tt> package. It is also available from the Debian
+ web mirrors at <tt><url name="/doc/packaging-manuals/menu-policy/"
+ id="http://www.debian.org/doc/packaging-manuals/menu-policy/";></tt>.
</p>
Have a nice Sunday,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
Reply to: