Bug#707851: Proposed changes on menu systems
On Sun, Feb 02, 2014 at 04:53:57PM +0100, Markus Koschany wrote:
> Hello Charles,
>
> On 02.02.2014 14:00, Charles Plessy wrote:
> [...]
> > I think that the absence of a feature in the Debian Policy is not a good
> > justification for refusing a patch that is not invasive and does not require
> > further attention.
> >
> > We should assume people's good faith on both sides. Because a counter-argument
> > to yours would be that "people will use the presence of the Debian menu in the
> > Debian policy as a justification to file serious bugs on packages and bully
> > maintainers to do a work that they do not want to contribute by themselves".
>
> It depends on the wording. Someone who "bullied" maintainers about menu
> files in the past and filed serious bugs against such packages was wrong
> and simply abused the severity level. The Policy recommended menu files
> but without ever using the word "must".
>
> I think it is more likely and thus a greater danger, that people drop
> menu files from working packages because of missing support by Debian's
> Policy, than that we will see antisocial behavior from promoting the
> Debian menu as an alternative menu system.
>
> But to make my point of view clear: I agree with Sune's proposal to
> soften the wording of Debian's policy regarding menu files. It is
> completely sensible to recommend the xdg menu for all desktop
> applications. In my opinion policy should give clear advice for
> maintainers to provide these desktop files. I just don't see the urgent
> need to move the Debian menu to the attic right now.
>
> I would like to ask the Policy editors to consider the following:
>
> 1. The maintainer of Debian's menu package, Bill Allombert, is active
> and still supportive of his package. (See his remarks in this thread)
> 2. The Debian menu is well documented and mature. It just works for its
> target audience.
> 3. Creating and maintaining menu files is not a burden, especially if
> someone wrote the menu file for the maintainer and provided a patch.
> 4. Not all but a lot of packages already ship menu files. In some areas
> of Debian menu file support is already excellent.
>
> To be more precise, out of 353 source packages in main which are
> maintained by the Debian Games Team, only 17 are missing either a
> desktop or menu file or both.
>
> > As you probably see in your release goal, there are packages from your own team
> > that have bugs tagged desktop-integration related to menus, which are old of
> > multiple monthes and still not fixed. From this I conclude that the problem is
> > not obstruction from a minority of maintainers, but lack of manpower.
>
> Lack of manpower is partly an issue but not decisive. Most bug reports
> were filed because of a missing icon entry for the menu file. That's a
> very minor issue and I only expect a fix for that if someone has to fix
> another problem or make a regular upload.
>
> > In that sense, I am getting concerned that having the Policy encouraging work
> > on the Debian Menu is counter-productive. If there is no vibrant community
> > to keep the Debian Menu alive (and your release goal brilliantly demonstrate
> > that there is not much momentum), then it is better to let it dissapear.
>
> As I have pointed out before, I rather think that suggesting the Debian
> menu as an alternative menu system is more beneficial for Debian's users
> than to let it disappear. In many packages there is already a working
> system in place. Why not make use of it and tolerate a single menu file?
> I would love to see the Debian Policy recommend desktop files but still
> suggest the Debian menu as an alternative. That's all.
>
> > Are you yourself a user of the Debian menu ?
>
> Yes, of course. You will find a lot of articles on my blog at gambaru.de
> how to build lightweight desktop environments and to make old hardware
> useful again. Unfortunately those articles are only available in German
> but feel free to contact me, if you need some advice in this area.
This is just one mail among other in favor of keeping the section about the
Debian menu system in the policy document, which have been overlooked.
So in the spirit of going forward, I would suggest to restrict ourself
to documenting the FreeDesktop files.
I join a patch which is essentially Charles patch without the demotion of
the Debian menu system.
Some comment on the patch:
I note that some important aspect of the XDG specification are not included.
While it is not necessarily a requirement for policy inclusion, it could be
helpful to document the .menu files used by desktop environment and how the
Categories relates to the menu layout the users will see.
Again, apology for the long delay, but sometime this is necessary.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
diff --git a/policy.sgml b/policy.sgml
index f4e4281..be59974 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -8088,6 +8088,73 @@ Reloading <var>description</var> configuration...done.
</p>
</sect>
+ <sect id="desktop entries">
+ <heading>FreeDesktop desktop entries</heading>
+
+ <p>
+ Packages shipping applications that comply with minimal requirements
+ described below for integration with desktop environments should
+ register these applications in the desktop menu, following the
+ <em>FreeDesktop</em> standard, using text files called
+ <em>desktop entries</em>. Their format is described in the
+ <em>Desktop Entry Specification</em> at
+ <url id="http://standards.freedesktop.org/desktop-entry-spec/latest/";>
+ and complementary information can be found in the
+ <em>Desktop Menu Specification</em> at
+ <url id="http://standards.freedesktop.org/menu-spec/latest/";>.
+ </p>
+
+ <p>
+ The desktop entry files are installed by the packages in the
+ directory <file>/usr/share/applications</file> and the FreeDesktop
+ menus are refreshed using <em>dpkg triggers</em>. It is therefore
+ not necessary to depend on packages providing FreeDesktop menu
+ systems.
+ </p>
+
+ <p>
+ 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 FreeDesktop 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>
+ </p>
+
+ <p>
+ Since the FreeDesktop menu is a cross-distribution standard, the
+ desktop entries written for Debian should be forwarded upstream,
+ where they will benefit to other users and are more likely to
+ receive extra contributions such as translations.
+ </p>
+
+ </sect>
+
<sect id="mime">
<heading>Multimedia handlers</heading>
Reply to: