[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 11:46:31 +0200
"Bernhard R. Link" <brlink@debian.org> wrote:

> * 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.

It generally starts when the user wants to open a file it can support.
It's not shown by default in GNOME either but that's the way that
upstream and the Debian maintainers want it to run. I've got no
problem with that.

> 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.

Would it be any use? Thunar is often a better bet for a non-GNOME
environment. Again, within GNOME, nautilus isn't usually started just
by running nautilus, users select somewhere to look at in nautilus
using the Places menu. Other environments have ways of selecting a
Place, like / or ~ if nothing else.

These are special cases which are easily explained by their intended
use cases and do not need to be hit with the Policy stick.

> > 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?

No. Firmly, NO.

> 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

I would have probably closed such bug reports. It is useless pedantry
to assert that one must be used in favour of the other. There is no
substantive difference between the two. What will a user gain from the
change? The addition of a verb for some pedantic grammatical rule when
the verb itself is implied by the description of the thing as something
which is normally played, i.e. a game. Three extra characters, another
push upstream, another round of 30 translation updates, 30 bugs in the
BTS and a new upstream release. WTF?

Or you could just patch it in Debian and lose all the translations for
the original string and force the pedantry onto all users who
previously had a perfectly serviceable string in their own language.
Tell me, is that REALLY a result which Debian aspires to achieve??

I don't know about you but I'm 100% sure I've got a long long list of
things to do which are way more important than that kind of change.

> So perhaps it might make sense to include anything about that to avoid
> any rewriting later.

Disagree. It should be much more free form.
 
> > 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???

Most of the applications concerned are intended for specific
environments. I also think you are over-estimating how quickly I
get around to uploads for each of my packages - by a factor of about
50. There is no need to delay the implementation of desktop files
if we don't waste time creating a special Policy.

Abolish the current Menu Policy, let things go through the normal
process of improvements driven by lintian - which could include
removing debian/menu as a ReleaseGoal for Wheezy.

> 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).

There are mechanisms (inside and outside Debian) for people to ask
native English speakers to create the original strings which are then
sent to translators before the package is released.
 
Generally, programmers of most kinds shouldn't write the English
strings which go out for translation - whether native English speakers
or not. It can also be useful if programmers don't spend time creating
translations of strings into their own language. Translators who are
not programmers generally make a better translation. If they don't, the
problem lies with the programmers not marking up the strings in an
understandable manner.

e.g. "%s in %s reported %d! Aborting"
Without a comment about what kind of string gets substituted into each
of the %s placeholders and what the %d is all about, translators don't
have much of a clue. Such comments need to come from the programmers.

Far better to file bugs to make the original markup clearer than to
argue about the grammar of the translation.

> > 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.

So we need a single line addition to the main Debian Policy that "there
is no Menu Policy - follow the lintian warnings". Done.

More rules just encourage more pedants who pick on all the things which
aren't stipulated in the rules.

> >  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.

Just do without it, entirely. Much better for everyone.
 
> > 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. 

s/things/some things/

> And for some things like menus or package descriptions that
> is a big value.

Disagree.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgppp45_NthDs.pgp
Description: PGP signature


Reply to: