Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
* Neil Williams <codehelp@debian.org> [110420 10:47]:
> Have you examples of desktop files which are not "in shape" currently?
Well, for example currently in squeeze there is
/usr/share/menu/evince:
?package(evince):needs="X11" section="Applications/Viewers"\
title="Evince" command="/usr/bin/evince"\
hints="Documents,GNOME" icon="/usr/share/pixmaps/evince.xpm"
but the only .desktop for it has
Name=Document Viewer
GenericName=Document Viewer
Comment=View multi-page documents
and even
NoDisplay=true
So switching from menu to .desktop would remove classic WM users a way
to start it.
There is nautilus.menu
?package(nautilus):needs="X11" section="Applications/File Management" \
title="Nautilus" command="/usr/bin/nautilus" icon="/usr/share/pixmaps/nautilus.xpm"
but all .desktop files with nautilus in it have
OnlyShowIn=GNOME;
so this would not longer be startable.
> > 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.
That sounds better.
> 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.
Anything about the way this is expressed?
I've had gotten (and sent upstream) bug reports to change
Comment=A tetris like game with many levels
to
Comment=Play a tetris like game with many levels
So perhaps it might make sense to include anything about that to avoid
any rewriting later.
> There is absolutely no point in Policy mandating that this has to be:
>
> Name: ddd
> Comment: The Data Display Debugger, a graphical debugger frontend
> 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.
I'd have considered "Data Display Debugger" still the program name.
I do not suggest (and did not want to imply) to force the binary's name.
> 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.
Well, I'd say most Debian menu users are happy if there is a menu item
with the name of the program that starts it and do not want much more,
while the desktop file has much more fields that can be changed or
translated.
> I'm going to start dropping debian/menu files from my packages
> henceforth.
Is there any reason for this other that you want to piss of users
if they do not have the same choice about the window manager as you?
Sorry to be a bit harsh about that, but seriously???
> > [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.
I think that point can also be more suggestions than strict policy, but
please remember that most upstreams (though not the most prominent upstreams)
usually also have not heared much about any conventions for such files,
and are often not native speakers. (And more than enough free software
developers and DDs (including myself) fail miserably at writing understandable
things).
> 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.
I do not care, but it seems there are people that are. What I as maintainer
want is a way I can create a package so that I won't have to change things
later. So I'd prefer to have a policy that either states it has to have
something or that there is no need in that regard.
> We have enough problems with that level of pedantry with the
> apt cache Descriptions. Let it breathe.
> 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.
Not every sub policy must be a must in Debian policy. I think a should
could equally be at this point.
> The initial text above is far too
> prescriptive and dogmatic. Policy is not a stick to bash people with.
There is a often some value in having things consistent within an
distribution. And for some things like menus or package descriptions that
is a big value.
Also note that everyone has their pet projects and it is hard to guess what
other projects need. Having some clear rules makes this much easier.
The Debian menu has in the past be a very important 'selling point' for Debian.
Being able to just install a package and have it show up in every of the many
different window managers your users use and being able to be able to help
people without having to know their WM first are still quite nice things to have.
Bernhard R. Link
Reply to: