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

Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]

On Wed, 20 Apr 2011 09:12:52 +0200
"Bernhard R. Link" <brlink@debian.org> wrote:

> Some suggestions for a Debian .desktop policy[1]:

Do we actually need one? lintian makes a fairly decent job of this
currently and I have yet to see any specific examples of where desktop
files are a "joke" or not "in shape". (As long as the judgement is made
without undue pedantry.)

> 1) syntax according to freedesktop's Desktop Entry Specification

.. as validated by the desktop-file-validate utility, as used by

> 2) Name must be a name properly name the program and be unique enough
>    to be usable if multiple programs doing the same are in the menu.

2) Name can be the program name or a short alternative which describes
the function of the program, perhaps to make it easier to see why the
program name is what it is.

3) Comments should be used to describe the function of the program so
that users who are unfamiliar with the program name will be able to
understand how the program can help them achieve tasks or partake in an
activity. Comments should aim to distinguish the program from similar
programs which may appear in the same menu category.

Either the Name or the Comment can match parts of the apt-cache
description, if the package only contains a single desktop file.

e.g. ddd is useless as a Name. Data Display Debugger is OK as a Name,
particularly as the comment is "Graphical debugger frontend". 

There is absolutely no point in Policy mandating that this has to be:

Name: ddd
Comment: The Data Display Debugger, a graphical debugger frontend

(strings taken from the apt-cache Description (short))

It isn't worth arguing that the Name must be a program name (e.g. on the
basis that this would make it easier to manage packages) because there
is no direct link between the executable name and the binary package
name, especially when one package provides multiple executables.

It's probably easier to recommend that either the desktop Name or the
Comment should be similar to the apt-cache short description, or for
packages with multiple .desktop files, similar to parts of the long

lintian can check this, possibly with a lower certainty than the other
tests but that is fully appropriate IMHO.

> 4) Categories must be according to freedesktop's Desktop Menu
>    Specification, appendix A [TODO: what version? Always latest?].

Good practice to have a version but AFAICT it hasn't changed
substantially since I started referencing it. We have tools to do the

> [1] As some people always complain about the need to create menu files,
>     let's try to look how .desktop files can get in shape that they might
>     replace menu files in some future.

Have you examples of desktop files which are not "in shape" currently?

I complain about creating a menu file because a desktop file is just so
much more helpful and useful. I've never had a bug report or comment
about the content of a menu file - I have had helpful suggestions on
improving desktop files as well as interest from translators (to
translate the entirety of the program) simply because the desktop file
contents caught their eye.

I'm going to start dropping debian/menu files from my packages

> [2] I'm still looking for some definition of what that should look like.
>     I remember many bugs files about those in the past, but no
>     definition but "something like this 3 examples and I recognize it if
>     it is wrong". For example is it imperative? or an infitive clause?
>     or something else? What exactly does "should not be redundant with
>     the values of Name and GenericName" from D-E-S mean?

Do we need to specify imperative or just leave it as descriptive? It's
a comment, it's meant to be helpful and relevant to users and the kinds
of tasks and activities which users would be expected to want to
achieve. "should not be redundant" expresses that the comment should
provide additional descriptive content beyond just the program name. So
if the Name is "Contacts", the Comment can be "Address book" but it
shouldn't just be "Manage contacts". Policy doesn't need to stipulate
that the comment needs to be "Add, update, delete and export entries
from your address book which is also accessible via Evolution" but it
might be improved to "Manage your address book" or similar - that
should be a wishlist bug, not a stipulation of Policy.

Just because it's Policy does not mean that every last minutiae has to
be precisely and uniquely referenced. There is absolutely no need for
Policy to stipulate whether a verb is necessary and other such
nonsense. We have enough problems with that level of pedantry with the
apt cache Descriptions. Let it breathe.

> [3] What does Xaw programs use? And what SDL programs?
> [4] I suggest a lintian warning for this for everything that has not
>     "Applet" or "Settings" in Categories.

If we're going to bother with this at all, then most of the above must
have *must* downgraded to *should*. At no point must menu entries be
allowed to become the source of RC bugs unless the file validity
breaks the build from source. The initial text above is far too
prescriptive and dogmatic. Policy is not a stick to bash people with.

I'd prefer to simply delete the Debian Menu Policy and let lintian
and the BTS manage the desktop files.

One less Policy document would be a net win for Debian.


Neil Williams

Attachment: pgpy7e7Qjeeig.pgp
Description: PGP signature

Reply to: