Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
* Sune Vuorela nos...@vuorela.dk [110419 15:24]: The OnlyShowIn/NotShowIn items should normally not be used, unless there is a tight integration between a DE and the app itself. e.g. a tool to configure the appearance of Plasma should probably have OnlyShowIn=KDE What exceptions are there? Should there be a lintian warning about those? A lintian warning doesn't make sense. it can't be automatically determined what a application do or does not, and what it works with. People can still add lintion overrides. It makes sense for warnings for things that are either common bugs or very uncommon situations. For example a warning if there is not other .desktop with the same command in the same package and the Category does not contain Settings. And the Gnome people seems to prefer adding OSI=Gnome, where others have a equivalent As long as that will not change or there is no added .desktop with NSI=Gnome in the same package I guess we can stop this discussion and just keep requiring menu files, as that makes .desktop files simply useless for classic window managers[1]. Well, I hope there is something similar, but getting this documentation for users is very hard to get out of the xdg specs. There might be something similar written. I haven't looked for it. But there is various graphical applications for editing your menu, which is probably the preferred form for most our users. Debian users are administrators. There might be a even a mojority of people administrating only a personal computer, but being able to globally config a menu is very important for the rest. Having to tell each new user to then with the window manager[1] you prefer see how you configure menus in there, then add an item for this and delete the menu for that then... is the opposite of user-friendly in my eyes. Bernhard R. Link [1] called something like legacy X session types in newspeak. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110420064732.ga20...@pcpool00.mathematik.uni-freiburg.de
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On 2011-04-18, Bernhard R. Link brl...@debian.org wrote: Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. what do you miss from the xdg specs? /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniqqf55.p7v.nos...@sshway.ssh.pusling.com
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
* Sune Vuorela nos...@vuorela.dk [110419 09:41]: On 2011-04-18, Bernhard R. Link brl...@debian.org wrote: Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. what do you miss from the xdg specs? The Desktop Entry Specification mostly describes the format, with some very short sentences about Name, GenericName and Comment. Categories only refers to the Desktop Menu Specification (which only handles OnlyShownIn and NotShownIn though not advertised here). The Desktop Menu Specification (which for the most interesting stuff to users like where things are again refers to the desktop base directory specification and now finally even got a link to that...) finally has in the appendix a list of Registered Categories and values for OnlyShowIn and NotShowIn. Most of those Categories have a description of only one or two words (unless counting a then most have two or three). OnlyShowIn/NotShownIn only gives meaning. There is nothing that says when those should be used (or whether they may be used in Debian). Compare this to http://www.debian.org/doc/packaging-manuals/menu.html/ Especially I miss something as easy to read and as complete in one place as http://www.debian.org/doc/packaging-manuals/menu.html/ch3.html; and http://www.debian.org/doc/packaging-manuals/menu.html/ch6.html;. And in terms of policy I miss a better description of the Categories, better rules how Name/GenericName/Comment should be written and when OnlyShowIn/NotShownIn are to be used. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419101301.ga6...@pcpool00.mathematik.uni-freiburg.de
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On 2011-04-19, Bernhard R. Link brl...@debian.org wrote: * Sune Vuorela nos...@vuorela.dk [110419 09:41]: On 2011-04-18, Bernhard R. Link brl...@debian.org wrote: Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. what do you miss from the xdg specs? The Desktop Entry Specification mostly describes the format, with some very short sentences about Name, GenericName and Comment. Name is the application name, as named by upstream GenericName is a more generic name of the type of application Comment is optional Name=Konsole GenericName=Terminal Name=Gedit GenericName=Editor Name=KDevelop GenericName=Integrated Development Environment Comment could be something like Comment=Launch a terminal window Comment=Edit your text files Comment=Develop applications Most of those Categories have a description of only one or two words (unless counting a then most have two or three). I actually think the one or two words is enough to know where to put things. It could of course use more words to look like chapter 3 in the debian menu policy, but I think it is more words just to use more words. OnlyShowIn/NotShownIn only gives meaning. There is nothing that says when those should be used (or whether they may be used in Debian). The OnlyShowIn/NotShowIn items should normally not be used, unless there is a tight integration between a DE and the app itself. e.g. a tool to configure the appearance of Plasma should probably have OnlyShowIn=KDE http://www.debian.org/doc/packaging-manuals/menu.html/ch6.html;. I guess one can write something similar. but basically it is syntax changes and 's,.menu,.local/share/applications,' And in terms of policy I miss a better description of the Categories, better rules how Name/GenericName/Comment should be written and when OnlyShowIn/NotShownIn are to be used. Does my comments here clear it up for you? (then we can talk about making docs out of it) /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniqqp40.p7v.nos...@sshway.ssh.pusling.com
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On Mon, 18 Apr 2011 15:50:29 +0200 Bernhard R. Link brl...@debian.org wrote: * Andreas Tille andr...@an3as.eu [110418 15:33]: As far as I understood [1] fvwm 2.6 now can use XDG menus. So it might be that even fvwm users will be happy about desktop files. Can we now come back to the discussion whether it might make sense to have desktop files for desktop applications? As I said in multiple other discussions about this: Please write a policy how .desktop files in Debian should look like and some documentation for maintainers what the categories means and some documentation for users how to do the basic things like overriding a menu entry. Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. How can the old Debian menu system be considered as working when it has never supported translation? All those titles and longtitles, not a single one can be shown as a translated string. For that reason alone, the old Debian menu system should be withdrawn as not fit for release. It doesn't matter about documentation for developers using the system, what matters is that users don't get the descriptive text in their own language even if 100% of all other translatable strings exist. Developers can add their own docs to a Wiki page - come on, that's utterly trivial. *Prohibiting* translation of descriptive text which is intended to be helpful to users ought to be an RC bug in and of itself. Fine if the translation doesn't exist but menu actively prevents translation. That is simply BUST - RC bust IMNSHO. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpR4Lx3naDVh.pgp Description: PGP signature
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
* Neil Williams codeh...@debian.org [110419 12:50]: How can the old Debian menu system be considered as working when it has never supported translation? All those titles and longtitles, not a single one can be shown as a translated string. Let's not start about longtitles, those Comments found in .desktop files are usually a joke. For the names translation is something that almost does not exist, even with .desktop files. (There exists some transliteration into other character sets where .desktop is of course superior). From looking on a local squeeze system here at the .desktop file not specific to the gnome setting menu, there are 54 with no German name translation, 10 where the German translation is the same, 19 where there is a German translation, but almost all of them seem to have missed the difference between Name and GenericName (especially things like totem, evince, eog, file-roller, nautilus). And the debian menu has supported translations since longer than .desktop files even exist. It just has the strange idea that it might be easier for translators to supply one file with all the translations of their language instead of having to change a file in virtually every package in the distribution to add their language. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419113443.ga7...@pcpool00.mathematik.uni-freiburg.de
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
* Sune Vuorela nos...@vuorela.dk [110419 12:32]: On 2011-04-19, Bernhard R. Link brl...@debian.org wrote: * Sune Vuorela nos...@vuorela.dk [110419 09:41]: On 2011-04-18, Bernhard R. Link brl...@debian.org wrote: Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. what do you miss from the xdg specs? The Desktop Entry Specification mostly describes the format, with some very short sentences about Name, GenericName and Comment. Name is the application name, as named by upstream GenericName is a more generic name of the type of application Comment is optional Name=Konsole GenericName=Terminal Name=Gedit GenericName=Editor Name=KDevelop GenericName=Integrated Development Environment What about nautilus.desktop's (at least in squeeze): Name=File Manager and no GenericName. Would that be a policy violation? Is that allowed if has a restrictive OnlyShowIn=. Must programs that are also useable outside that session type also have a menu item with a less generic name? Comment could be something like Comment=Launch a terminal window Comment=Edit your text files Comment=Develop applications I've seen quite some bug reports about those. What should it contain? A verb phrase describing what? (Might also help translations. The English text might be both an imperative or an infinitive, the German translations seem to translate it as infinitive clause). The OnlyShowIn/NotShowIn items should normally not be used, unless there is a tight integration between a DE and the app itself. e.g. a tool to configure the appearance of Plasma should probably have OnlyShowIn=KDE What exceptions are there? Should there be a lintian warning about those? What about NotShownIn? Is e.g. squeeze's gnome-screenshot.desktop's NotShowIn=KDE; a bug and should it have been OnlyShowIn=GNOME; or nothing at all? http://www.debian.org/doc/packaging-manuals/menu.html/ch6.html;. I guess one can write something similar. but basically it is syntax changes and 's,.menu,.local/share/applications,' Well, I hope there is something similar, but getting this documentation for users is very hard to get out of the xdg specs. And in terms of policy I miss a better description of the Categories, better rules how Name/GenericName/Comment should be written and when OnlyShowIn/NotShownIn are to be used. Does my comments here clear it up for you? (then we can talk about making docs out of it) Unless there are many bugs around currently, I think this rather needs a policy for those fields rather then simply docs. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419124620.ga8...@pcpool00.mathematik.uni-freiburg.de
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On 2011-04-19, Bernhard R. Link brl...@debian.org wrote: What about nautilus.desktop's (at least in squeeze): Name=File Manager and no GenericName. Would that be a policy violation? I would consider that a bug. At least my default Plasma Desktop menu shows the menu as GenericName (in black on white) Name (in gray on white, only when hovered) The OnlyShowIn/NotShowIn items should normally not be used, unless there is a tight integration between a DE and the app itself. e.g. a tool to configure the appearance of Plasma should probably have OnlyShowIn=KDE What exceptions are there? Should there be a lintian warning about those? A lintian warning doesn't make sense. it can't be automatically determined what a application do or does not, and what it works with. What about NotShownIn? Is e.g. squeeze's gnome-screenshot.desktop's NotShowIn=KDE; a bug and should it have been OnlyShowIn=GNOME; or nothing at all? I don't know what gnome-screenshot does, but there are many cases where NotShowIn=KDE is a better choice than OSI=GNOME, because xfce and lxde also uses gnome specific stuff. And the Gnome people seems to prefer adding OSI=Gnome, where others have a equivalent, no what, just like there is implemented a blacklist in the gnome menu that blacklists apps that could be usable from the gnome menu. (kwrite, digikam, ...). http://www.debian.org/doc/packaging-manuals/menu.html/ch6.html;. I guess one can write something similar. but basically it is syntax changes and 's,.menu,.local/share/applications,' Well, I hope there is something similar, but getting this documentation for users is very hard to get out of the xdg specs. There might be something similar written. I haven't looked for it. But there is various graphical applications for editing your menu, which is probably the preferred form for most our users. And in terms of policy I miss a better description of the Categories, better rules how Name/GenericName/Comment should be written and when OnlyShowIn/NotShownIn are to be used. Does my comments here clear it up for you? (then we can talk about making docs out of it) Unless there are many bugs around currently, I think this rather needs a policy for those fields rather then simply docs. There are most likely many bugs around. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniqr369.p7v.nos...@sshway.ssh.pusling.com
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On Tue, 19 Apr 2011 13:34:43 +0200 Bernhard R. Link brl...@debian.org wrote: * Neil Williams codeh...@debian.org [110419 12:50]: How can the old Debian menu system be considered as working when it has never supported translation? All those titles and longtitles, not a single one can be shown as a translated string. Let's not start about longtitles, those Comments found in .desktop files are usually a joke. I disagree - my own packages and those I've worked on have usable comment strings and usually a dozen translations of Name and Comment. On my own box, I don't see any Comment fields that could be classified as a joke. Most contain a description of what the program does, as the Comment field should. If that needs improving, file wishlist bugs. At least it can be easily fixed and subsequently maintained. For the names translation is something that almost does not exist, even with .desktop files. (There exists some transliteration into other character sets where .desktop is of course superior). Then that is lazy of the upstream. Most programs can do with a longer name than the program name. File bugs. At least these can be easily patched and then submitted for translation using tools and translation mechanisms with which all translators are already familiar. The Name probably should include the name but there are good reasons to specify that the Name field should contain the program name and a short description. Foo text editor is much better than just foo. It might be worth having a lintian warning for where Name= exactly matches the Exec field, ignoring case and stripping off any arguments in the Exec field, but then what is wrong with a terminal application describing itself as Terminal and a comment of Use the command line ? From looking on a local squeeze system here at the .desktop file not specific to the gnome setting menu, there are 54 with no German name translation, 10 where the German translation is the same, 19 where there is a German translation, but almost all of them seem to have missed the difference between Name and GenericName (especially things like totem, evince, eog, file-roller, nautilus). I think that might be a historical thing - less than 10% of .desktop files on my system have a Generic Name field. However, those which trouble you can be easily fixed with wishlist bugs and easily translated into any supported locale. And the debian menu has supported translations since longer than .desktop files even exist. It just has the strange idea that it might be easier for translators to supply one file with all the translations of their language instead of having to change a file in virtually every package in the distribution to add their language. Are you talking about menu-l10n ? WOW! THREE translated locales. THREE out of several hundred supportable locales with .desktop files! (One of the three is only at 20% translated.) A popcon of 0.2% and not updated since Squeeze, so no end of missing applications and changed strings. How is that meant to keep pace with changes in the distribution? Why would a centralised file be a good example anyway? man-db has a very complex task and quite poor coverage in many locales and that's only a subset of all manpages. Program messages and debconf strings cannot be centralised. The whole point is that a fully translated system is a major undertaking and requires filing updates with many many packages anyway. It certainly doesn't look as if the centralised approach used by menu-l10n is actually attracting any translation effort. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp5H0iulKKDr.pgp Description: PGP signature
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
On Tue, Apr 19, 2011 at 04:16:23PM +0100, Neil Williams wrote: On Tue, 19 Apr 2011 13:34:43 +0200 Bernhard R. Link brl...@debian.org wrote: [...] And the debian menu has supported translations since longer than .desktop files even exist. It just has the strange idea that it might be easier for translators to supply one file with all the translations of their language instead of having to change a file in virtually every package in the distribution to add their language. Are you talking about menu-l10n ? WOW! THREE translated locales. THREE out of several hundred supportable locales with .desktop files! (One of the three is only at 20% translated.) A popcon of 0.2% and not updated since Squeeze, so no end of missing applications and changed strings. How is that meant to keep pace with changes in the distribution? [...] And those translations can't be shared with upstream, so all that effort is being duplicated. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110419155055.gw2...@decadent.org.uk
Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
Hi, DPL asked us to increase traffic on devel - so I'd like to warm up a recent discussion On Sat, Mar 05, 2011 at 04:22:01PM -0800, Manoj Srivastava wrote: Fair enough. Would you, then, be satisfied by my answer that they are used? I am a current real life user of fvwm, and I am on the mailing lists for the fvwm project with other real life users and developers; and my expeirnces, and the chatter on the list, do not lead me to believe that menus are unused. As far as I understood [1] fvwm 2.6 now can use XDG menus. So it might be that even fvwm users will be happy about desktop files. Can we now come back to the discussion whether it might make sense to have desktop files for desktop applications? Kind regards Andreas. [1] http://lwn.net/Articles/438781/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418133316.gg18...@an3as.eu
Re: Warm up discussion about desktop files [Was: Lintian check for missing desktop files?]
* Andreas Tille andr...@an3as.eu [110418 15:33]: As far as I understood [1] fvwm 2.6 now can use XDG menus. So it might be that even fvwm users will be happy about desktop files. Can we now come back to the discussion whether it might make sense to have desktop files for desktop applications? As I said in multiple other discussions about this: Please write a policy how .desktop files in Debian should look like and some documentation for maintainers what the categories means and some documentation for users how to do the basic things like overriding a menu entry. Currently there is none of this[1]. I think it makes no sense to discuss if things should have desktop files or whether it makes sense to remove the old working system. Bernhard R. Link P.S.: While icewm does support XDG menu the first I do is disable it so that users are not confused by it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110418135029.gb24...@pcpool00.mathematik.uni-freiburg.de
