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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
