FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 04-20-2011, 07:12 AM
"Bernhard R. Link"
 
Default some suggestions towards a Debian .desktop policy

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

1) syntax according to freedesktop's Desktop Entry Specification
[TODO: always the latest, fix some version and increase that at
fixed points?]

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

3) Comment, if it exists, must be <...>[2]

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

5) Categories must contain applicable KDE,GNOME,GTK,Qt,Motif,Java[3]
so that a menu manager cat filter out things not matching
the UI look&feel if wanted.

6) A .desktop file is allowed to break above rules if is has a
OnlyShownIn limiting it to some environment(s) it belongs to.

7) In case of 6) there must be a .desktop file with the same
command and adhering to this policy, unless that command cannot
be run (or cannot work) outside this environment[3].

8) An alternative .desktop as in 7) might have a NotShownIn,
otherwise it must not have one.

What do you think?

Bernhard R. Link

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

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

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110420071252.GB20107@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110420071252.GB20107@pcpool00.mathematik.uni-freiburg.de
 
Old 04-20-2011, 08:13 AM
Josselin Mouette
 
Default some suggestions towards a Debian .desktop policy

Le mercredi 20 avril 2011 Ă* 09:12 +0200, Bernhard R. Link a Ă©crit :
> Some suggestions for a Debian .desktop policy[1]:
>
> 1) syntax according to freedesktop's Desktop Entry Specification
> [TODO: always the latest, fix some version and increase that at
> fixed points?]
>
> 2) Name must be a name properly name the program and be unique enough
> to be useable if multiple programs doing the same are in the menu.
>
> 3) Comment, if it exists, must be <...>[2]
>
> 4) Categories must be according to freedesktop's Desktop Menu
> Specification, appendix A [TODO: what version? Always latest?].
>
> 5) Categories must contain applicable KDE,GNOME,GTK,Qt,Motif,Java[3]
> so that a menu manager cat filter out things not matching
> the UI look&feel if wanted.
>
> 6) A .desktop file is allowed to break above rules if is has a
> OnlyShownIn limiting it to some environment(s) it belongs to.
>
> 7) In case of 6) there must be a .desktop file with the same
> command and adhering to this policy, unless that command cannot
> be run (or cannot work) outside this environment[4].

I disagree with this rule. Menus are editable, so if a program is meant
for an environment it should not be displayed by default in others. For
example, Thunar works perfectly fine outside Xfce, but you don’t want to
show it in KDE or GNOME.

> 8) An alternative .desktop as in 7) might have a NotShownIn,
> otherwise it must not have one.

Same here.

> What do you think?

I would add at least two other rules:

If the entry has Terminal=true, it must also have
NoDisplay=true.

If the program is not useful in the general case and might have
been installed as a dependency for something mostly unrelated,
it must have NoDisplay=true.

The second case is to handle things like sun-java* crap and similar
ones. They get installed just because you installed a Java program, but
you don’t want them in your menus, you just want the program to work.

With NoDisplay=true these entries can be enabled in a menu editor, so
that should be enough.

> [4] I suggest a lintian warning for this for everything that has not
> "Applet" or "Settings" in Categories.

Sounds just as useful as the “su-wrapper-not-su-to-root” check - meaning
people adding bugs in their uploads just because lintian asked them to.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1303287182.4084.56.camel@pi0307572">http://lists.debian.org/1303287182.4084.56.camel@pi0307572
 
Old 04-20-2011, 08:37 AM
"Bernhard R. Link"
 
Default some suggestions towards a Debian .desktop policy

* Josselin Mouette <joss@debian.org> [110420 10:14]:
> > 5) Categories must contain applicable KDE,GNOME,GTK,Qt,Motif,Java[3]
> > so that a menu manager cat filter out things not matching
> > the UI look&feel if wanted.
> >
> > 6) A .desktop file is allowed to break above rules if is has a
> > OnlyShownIn limiting it to some environment(s) it belongs to.
> >
> > 7) In case of 6) there must be a .desktop file with the same
> > command and adhering to this policy, unless that command cannot
> > be run (or cannot work) outside this environment[4].
>
> I disagree with this rule. Menus are editable, so if a program is meant
> for an environment it should not be displayed by default in others. For
> example, Thunar works perfectly fine outside Xfce, but you don’t want to
> show it in KDE or GNOME.

The point of that rule is that some classic Window Manager[1] should
have all the installed programs available with sensible names.
Such users prefer to use whatever program is best suited for the task
and not the one looking in a specific way, so one wants to have all
available. If one menu provider does want to limit that, it should offer
some option to hide things without the right KDE/GNOME/GTK/Qt/Motif/Java
Categories.

> If the entry has Terminal=true, it must also have
> NoDisplay=true.

Again, that should be an option in the menu provider. If the point is of
hiding programs with an user-interface you do not like, that is the job
of the environment not wanting those. (Especially as other providers
cannot know when NoDisplay means "only for mime type handling" and when
it is "deemed to ugly by someone").

Bernhard R. Link

[1] I mean something like "legacy X Session" in newspeak.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110420083742.GA20901@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110420083742.GA20901@pcpool00.mathematik.uni-freiburg.de
 
Old 04-20-2011, 08:47 AM
Neil Williams
 
Default some suggestions towards a Debian .desktop policy

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/
 
Old 04-20-2011, 08:57 AM
Paul Wise
 
Default some suggestions towards a Debian .desktop policy

On Wed, Apr 20, 2011 at 4:47 PM, Neil Williams <codehelp@debian.org> wrote:

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

desktop-file-validate is not used by lintian, perhaps there should be
a test similar to the man-db test though.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: BANLkTinuRpscJzkzQAREQLsWCqS25ZgbyA@mail.gmail.com ">http://lists.debian.org/BANLkTinuRpscJzkzQAREQLsWCqS25ZgbyA@mail.gmail.com
 
Old 04-20-2011, 09:24 AM
Sune Vuorela
 
Default some suggestions towards a Debian .desktop policy

On 2011-04-20, Neil Williams <codehelp@debian.org> wrote:
> e.g. ddd is useless as a Name. Data Display Debugger is OK as a Name,
> particularly as the comment is "Graphical debugger frontend".=20

what is the name of that app? is it 'ddd' or 'Data Display Debugger'?

Graphical debugger frontend should be in GenericName, not in Comment.

GenericName is the ... Joe Average friendly name for the application.

Name=LibreOffice Writer
GenericName=Word Processor

or something like that. Name should of course not be the executable
name, but the actual name of the application.

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

Sounds like a good idea.


I think we should actually try to investigate how different 'menus' is
using the desktop entries.

KDE Plasma Desktop, default kickoff menu: prefers to show GenericName,
falls back to Name. When hovered, a gray version of Name is showed,
if this is different from what's showed already

KDE Plasma Desktop, classic menu: Shows Name (GenericName), or just
Name, if they are the same

KDE Plasma Netbook: Shows Name.

I haven't (as a user) found any where where the Comment is shown in the
above menus.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: slrniqt9hu.p7v.nospam@sshway.ssh.pusling.com">http ://lists.debian.org/slrniqt9hu.p7v.nospam@sshway.ssh.pusling.com
 
Old 04-20-2011, 09:45 AM
Simon McVittie
 
Default some suggestions towards a Debian .desktop policy

On Wed, 20 Apr 2011 at 09:24:14 +0000, Sune Vuorela wrote:
> I think we should actually try to investigate how different 'menus' is
> using the desktop entries.

GNOME Shell: displays only Name in the applications menu; displays only Name
when you hover over "favourite" apps in the dock; type-ahead search appears
to look in the Name and the Comment but not the GenericName.

For those interested in investigating different desktops' menus, Ekiga in
unstable makes a good test-case (although probably not a great example of
doing menu entries right), because all its strings are different:

.desktop:
Name=Ekiga Softphone
GenericName=IP Telephony, VoIP and Video Conferencing
Comment=Talk to people over the Internet

.menu:
title="Ekiga"
longtitle="Ekiga: Free Your Speech"
description="The Ekiga Voice and Video Over IP Suite"

Regards,
S


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110420094552.GA18358@reptile.pseudorandom.co.uk" >http://lists.debian.org/20110420094552.GA18358@reptile.pseudorandom.co.uk
 
Old 04-20-2011, 09:46 AM
"Bernhard R. Link"
 
Default some suggestions towards a Debian .desktop policy

* 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110420094631.GA21146@pcpool00.mathematik.uni-freiburg.de">http://lists.debian.org/20110420094631.GA21146@pcpool00.mathematik.uni-freiburg.de
 
Old 04-20-2011, 11:12 AM
Neil Williams
 
Default some suggestions towards a Debian .desktop policy

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/
 
Old 04-20-2011, 11:58 AM
Josselin Mouette
 
Default some suggestions towards a Debian .desktop policy

Le mercredi 20 avril 2011 Ă* 10:37 +0200, Bernhard R. Link a Ă©crit :
> > > 7) In case of 6) there must be a .desktop file with the same
> > > command and adhering to this policy, unless that command cannot
> > > be run (or cannot work) outside this environment[4].
> >
> > I disagree with this rule. Menus are editable, so if a program is meant
> > for an environment it should not be displayed by default in others. For
> > example, Thunar works perfectly fine outside Xfce, but you don’t want to
> > show it in KDE or GNOME.
>
> The point of that rule is that some classic Window Manager[1] should
> have all the installed programs available with sensible names.
> Such users prefer to use whatever program is best suited for the task
> and not the one looking in a specific way, so one wants to have all
> available. If one menu provider does want to limit that, it should offer
> some option to hide things without the right KDE/GNOME/GTK/Qt/Motif/Java
> Categories.

Are you serious? What kind of filtering rules could be used here?

> > If the entry has Terminal=true, it must also have
> > NoDisplay=true.
>
> Again, that should be an option in the menu provider. If the point is of
> hiding programs with an user-interface you do not like, that is the job
> of the environment not wanting those. (Especially as other providers
> cannot know when NoDisplay means "only for mime type handling" and when
> it is "deemed to ugly by someone").

It’s not only a problem of ugliness. The #1 usability problem with the
Debian menu is the huge amount of entries. If you repeat this mistake
with the freedesktop menus, a menu system that has been nice so far
(nice, not great) would become almost as crappy as the previous
situation.

Said otherwise: you’re entitled to improve the situation for crapwm if
you want, but if you break GNOME in the process, I don’t see this as a
win.

--
.'`. Josselin Mouette
: :' :
`. `'
`-


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 1303300707.4084.264.camel@pi0307572">http://lists.debian.org/1303300707.4084.264.camel@pi0307572
 

Thread Tools




All times are GMT. The time now is 02:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org