On Wed, 20 Apr 2011 11:46:31 +0200 "Bernhard R. Link" <brl...@debian.org> wrote:
> * Neil Williams <codeh...@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/
pgpsFWU5jozBS.pgp
Description: PGP signature
