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 lintian. > 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 description. 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 rest. > [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 henceforth. > [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 ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpy7e7Qjeeig.pgp
Description: PGP signature