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
Re: Lintian check for missing desktop files?
On Sat, Mar 05, 2011 at 04:22:01PM -0800, Manoj Srivastava wrote: Do you have concrete data to add here, apart from speculation? I would be interested in such data (as the once and perhaps future maintainer of fvwm in Debian). I have no idea whether it is pure speculation or wrong intuition. I accept your argument as insider that the menu function in fvwm is actually used by some users. However, the other arguments to prefer desktop files over menu files remain valid unregarded this fact and there was also a solution suggested in this thread for fvwm users. So the point remains: We should start issuing lintian warnings about missing desktop files where it makes sense to be able to start a smooth transition. These files will be needed in any case if we might want to get rid of Debian menu completely, provide conversions or just leave menu files untouched. Kind regards Andreas. -- 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/20110306182434.ga14...@an3as.eu
Re: Lintian check for missing desktop files?
On Sun, Mar 06 2011, Andreas Tille wrote: On Sat, Mar 05, 2011 at 04:22:01PM -0800, Manoj Srivastava wrote: Do you have concrete data to add here, apart from speculation? I would be interested in such data (as the once and perhaps future maintainer of fvwm in Debian). I have no idea whether it is pure speculation or wrong intuition. I accept your argument as insider that the menu function in fvwm is actually used by some users. Thanks However, the other arguments to prefer desktop files over menu files remain valid unregarded this fact and there was also a solution suggested in this thread for fvwm users. Agreed. So the point remains: We should start issuing lintian warnings about missing desktop files where it makes sense to be able to start a smooth transition. These files will be needed in any case if we might want to get rid of Debian menu completely, provide conversions or just leave menu files untouched. If I recall correctly, there was some objection to creating a desktop file for every menu file that exists, have those objections been withdrawn (if memory serves me, the objection was to the sheer mass of menu files for applications and docs that did not make sense in a GNOME/KDE menu like hack or worm)? If not, are there criteria lintian will use to warn about some menu files not having a desktop file, and not others? manoj -- Old programmers never die, they just become managers. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/874o7g6qat@anzu.internal.golden-gryphon.com
Re: Lintian check for missing desktop files?
On Fri, Mar 04, 2011 at 06:52:39PM -0800, Manoj Srivastava wrote: I was a fan of fvwm for years and I even have configured my xfce with fvwm keycodes to have the same handling. However, if you ask me the typical fvwm user (if something like this exists at all) is most probably ignoring the menu and has rather configured his environment to fire up applications via key codes or fires up an xterm and types the command for an application. So while I do not really want to I would be surprised if that were indeed the case. If you look at the exemplar configuration file providedat fvwm.org, there is extensive use of menus -- and for non debian folk, yes, they tend to manually hard code application paths in menus; for Debian folks upstream even ships the default system.fvwm2rc with: Test (f /etc/X11/fvwm/menudefs.hook) + Debian Menu Popup /Debian Test (f /etc/X11/fvwm/menudefs.hook) + Re-read System Menu Read /etc/X11/fvwm/menudefs.hook Test (f /etc/X11/fvwm/menudefs.hook) + Update My Debian Menu PipeRead 'update-menus echo Read $./menudefs.hook' I do not question that these files *exist*. I simply question that they are *used* in real life. Kind regards Andreas. -- 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/20110305214427.gc30...@an3as.eu
Re: Lintian check for missing desktop files?
On Sat, Mar 05 2011, Andreas Tille wrote: On Fri, Mar 04, 2011 at 06:52:39PM -0800, Manoj Srivastava wrote: I was a fan of fvwm for years and I even have configured my xfce with fvwm keycodes to have the same handling. However, if you ask me the typical fvwm user (if something like this exists at all) is most probably ignoring the menu and has rather configured his environment to fire up applications via key codes or fires up an xterm and types the command for an application. So while I do not really want to I would be surprised if that were indeed the case. If you look at the exemplar configuration file providedat fvwm.org, there is extensive use of menus -- and for non debian folk, yes, they tend to manually hard code application paths in menus; for Debian folks upstream even ships the default system.fvwm2rc with: Test (f /etc/X11/fvwm/menudefs.hook) + Debian Menu Popup /Debian Test (f /etc/X11/fvwm/menudefs.hook) + Re-read System Menu Read /etc/X11/fvwm/menudefs.hook Test (f /etc/X11/fvwm/menudefs.hook) + Update My Debian Menu PipeRead 'update-menus echo Read $./menudefs.hook' I do not question that these files *exist*. I simply question that they are *used* in real life. 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. Do you have concrete data to add here, apart from speculation? I would be interested in such data (as the once and perhaps future maintainer of fvwm in Debian). manoj -- If I can have honesty, it's easier to overlook mistakes. Kirk, Space Seed, stardate 3141.9 Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87fwr16qty@anzu.internal.golden-gryphon.com
Re: Lintian check for missing desktop files?
On Thu, Mar 03, 2011 at 09:27:07PM -0800, Manoj Srivastava wrote: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) And fvwm, I was a fan of fvwm for years and I even have configured my xfce with fvwm keycodes to have the same handling. However, if you ask me the typical fvwm user (if something like this exists at all) is most probably ignoring the menu and has rather configured his environment to fire up applications via key codes or fires up an xterm and types the command for an application. So while I do not really want to loose fvwm menu in case there might be some constraints in a potential to be written desktop2menu I would not really regard this issue as urgent enough to stop what we would gain with overall proper desktop files. Kind regards Andreas. -- 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/20110304080215.gb7...@an3as.eu
Re: Lintian check for missing desktop files?
Le jeudi 03 mars 2011 à 22:56 +, Ben Hutchings a écrit : Lintian intentionally doesn't do this because the Debian maintainers of the desktop systems in Debian didn't want lots of desktop entries for applications without a GUI, which often currently have menu entries. Surely they can filter out entries with Terminal: true? Yeah sure, and leave users without the possibility to add a launcher for a terminal application? The correct solution is to use NoDisplay=true for such applications. This way they appear in the menu editor and can be enabled, but are not displayed in the menu by default. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1299225898.404.66.camel@meh
Re: Lintian check for missing desktop files?
On Fri, 04 Mar 2011 00:31:13 +0100 Sean Finney sean...@debian.org wrote: On Thu, 2011-03-03 at 23:01 +0100, Christoph Egger wrote: Sune Vuorela nos...@vuorela.dk writes: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) Last time I checked fluxbox and awesome where both debian menu only as well. instead of letting the tail wag the dog then with menu2desktop, wouldn't it be better to cater to these WM's/DE's by providing a desktop2menu? Still would feel like adding more layers where they should be removed though... ... and leave any non-English speakers without any translation support for the key texts which tell the user what the app behind the menu actually does? Nice. Lots of menu files don't even bother with an icon. Why is it acceptable for window managers to use a menu which cannot support translation? Why cater to such buggy software? Effectively, these window managers are ignoring LC_ALL, LANGUAGE and LANG by not using a menuing system capable of supporting translation. Why should Debian put up with that any longer? It's arguably more work to make 'menu' support translation, and then implement that in all packages, than for these window managers to be converted to use the existing desktop files. At least desktop files are available in distributions other than Debian. There are a lot more translated desktop files than there are applications with menu files but no desktop files. As all menu files are untranslatable, any change to these WM's should be to require the use of desktop files on the basis that at least some of the title strings will already be translated in the desktop files. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpSy47mwQnBs.pgp Description: PGP signature
Re: Lintian check for missing desktop files?
On 2011-03-04, Manoj Srivastava sriva...@ieee.org wrote: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) And fvwm, According to the internets, there is a fvwm-xdg-menu python script that is supposed to make the xdg/fdo menu in a format that fvwm can handle. /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/slrnin1b3d.rvp.nos...@sshway.ssh.pusling.com
Re: Lintian check for missing desktop files?
Le Fri, Mar 04, 2011 at 09:02:39AM +, Neil Williams a écrit : Why is it acceptable for window managers to use a menu which cannot support translation? Actually it does : http://lists.debian.org/debian-devel-announce/2008/05/msg00011.html This said, I think that translating the Debian menu is a terrible waste, since either the equivalent Desktop entries are either already translated, or if they are not, then the translator's work on the Debian menu entry is not directly forwardable upstream. As suggested in this thread an earlier, a possible compromise between the current duplication of work (two menu files) and dropping completely the Debian menu system would be to modify it to use natively Desktop menu entries. There is already a wiki page that lists similarities and differences: http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries That would require a C programmer to work on the Debian menu system. Perhaps it could be a project for the Google Summer of Code ? If we go that direction, I volunteer to help for the huge transition. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20110304103946.ga22...@merveille.plessy.net
Re: Lintian check for missing desktop files?
On Fri, 2011-03-04 at 09:04 +0100, Josselin Mouette wrote: Le jeudi 03 mars 2011 à 22:56 +, Ben Hutchings a écrit : Lintian intentionally doesn't do this because the Debian maintainers of the desktop systems in Debian didn't want lots of desktop entries for applications without a GUI, which often currently have menu entries. Surely they can filter out entries with Terminal: true? Yeah sure, and leave users without the possibility to add a launcher for a terminal application? You can surely distinguish user-added launchers from package-provided launchers. The correct solution is to use NoDisplay=true for such applications. This way they appear in the menu editor and can be enabled, but are not displayed in the menu by default. Could you arrange to interpret Terminal=true as NoDisplay=true, then? I'm just thinking that this policy of excluding terminal applications may not be appropriate for every desktop environment / window manager. (In particular, those without a menu editor that would allow overriding it.) Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Lintian check for missing desktop files?
Le vendredi 04 mars 2011 à 12:30 +, Ben Hutchings a écrit : On Fri, 2011-03-04 at 09:04 +0100, Josselin Mouette wrote: Le jeudi 03 mars 2011 à 22:56 +, Ben Hutchings a écrit : Surely they can filter out entries with Terminal: true? Yeah sure, and leave users without the possibility to add a launcher for a terminal application? You can surely distinguish user-added launchers from package-provided launchers. Not easily. Freedesktop specifies that there is a list of directories in which to search, and it doesn’t sound right (nor simple) to make exceptions based on pathnames. The correct solution is to use NoDisplay=true for such applications. This way they appear in the menu editor and can be enabled, but are not displayed in the menu by default. Could you arrange to interpret Terminal=true as NoDisplay=true, then? Doing that would mean it wouldn’t be possible to enable the application in the menu editor. I'm just thinking that this policy of excluding terminal applications may not be appropriate for every desktop environment / window manager. (In particular, those without a menu editor that would allow overriding it.) A possibility (for GNOME) would be to change gnome-menus-blacklist to automatically exclude Terminal=true entries, but that would also make it slower. But after all, this script is already the place where we deal with uncooperative maintainers and their useless XDG menu entries. -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling -- 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/1299242983.404.101.camel@meh
Re: Lintian check for missing desktop files?
On Fri, Mar 04, 2011 at 01:49:43PM +0100, Josselin Mouette wrote: Le vendredi 04 mars 2011 à 12:30 +, Ben Hutchings a écrit : On Fri, 2011-03-04 at 09:04 +0100, Josselin Mouette wrote: Le jeudi 03 mars 2011 à 22:56 +, Ben Hutchings a écrit : Surely they can filter out entries with Terminal: true? Yeah sure, and leave users without the possibility to add a launcher for a terminal application? You can surely distinguish user-added launchers from package-provided launchers. Not easily. Freedesktop specifies that there is a list of directories in which to search, and it doesn’t sound right (nor simple) to make exceptions based on pathnames. The correct solution is to use NoDisplay=true for such applications. This way they appear in the menu editor and can be enabled, but are not displayed in the menu by default. Could you arrange to interpret Terminal=true as NoDisplay=true, then? Doing that would mean it wouldn’t be possible to enable the application in the menu editor. [...] I thought you said it was possible to override NoDisplay=true in the menu editor. 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/20110304141540.gm19...@decadent.org.uk
Re: Lintian check for missing desktop files?
On Fri, Mar 04 2011, Andreas Tille wrote: On Thu, Mar 03, 2011 at 09:27:07PM -0800, Manoj Srivastava wrote: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) And fvwm, I was a fan of fvwm for years and I even have configured my xfce with fvwm keycodes to have the same handling. However, if you ask me the typical fvwm user (if something like this exists at all) is most probably ignoring the menu and has rather configured his environment to fire up applications via key codes or fires up an xterm and types the command for an application. So while I do not really want to I would be surprised if that were indeed the case. If you look at the exemplar configuration file providedat fvwm.org, there is extensive use of menus -- and for non debian folk, yes, they tend to manually hard code application paths in menus; for Debian folks upstream even ships the default system.fvwm2rc with: Test (f /etc/X11/fvwm/menudefs.hook) + Debian Menu Popup /Debian Test (f /etc/X11/fvwm/menudefs.hook) + Re-read System Menu Read /etc/X11/fvwm/menudefs.hook Test (f /etc/X11/fvwm/menudefs.hook) + Update My Debian Menu PipeRead 'update-menus echo Read $./menudefs.hook' loose fvwm menu in case there might be some constraints in a potential to be written desktop2menu I would not really regard this issue as urgent enough to stop what we would gain with overall proper desktop files. That is a decision that the project can of course make, though I think that would be a pity, and hope it shall not come to that. Could you please remind me why, given that we currently have a large number of menu files, that a menu2xdg script is not being considered as the better path moving forward? manoj -- The difference between a career and a job is about 20 hours a week. Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/87oc5qnurs@anzu.internal.golden-gryphon.com
Re: Lintian check for missing desktop files?
Manoj Srivastava sriva...@ieee.org writes: Could you please remind me why, given that we currently have a large number of menu files, that a menu2xdg script is not being considered as the better path moving forward? The menu and desktop category and classification systems are not particularly compatible, upstream ships desktop files (and often handles translation of desktop files) but Debian menu files are unique to us, and the desktop files do support a few features that menu files don't. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87d3m6s25j@windlord.stanford.edu
Lintian check for missing desktop files?
Hi, as I explained on Debian Med list[1] the existence of a desktop file is nearly as relevant as a manpage for a good user experience for users who are not that addicted to the command line as most of us are. I have not made any stats how many packages with applications which deserve a desktop file to show up in UIs implementing the freedesktop.org specification but I think I'm not wrong if I roughly estimate it with below 50%. In cases like this a lintian check has leaded to interesting results (see missing manpage). While I'm not a lintian expert I'd consider the following criterion as reasonable for a check * package has a file in /usr/bin * package name does not match '^lib' or '-doc$' * package has dependencies from typical libraries for freedesktop.org implementing interfaces which are for instance - libgnome2-0 - libkdeui5 - libxfce4ui-1-0 - libgtk-3-0 - libqtgui4 - ... Please excuse if my choice of the libraries is not optimal - I'm not an expert in this field but I hope you get the idea. * No file /usr/share/applications/*.desktop in the package If all these criterions are fullfilled a lintian warning about a missing desktop file could (should (!) IMHO) be issued. What do you think? Kind regards Andreas. [1] http://lists.debian.org/debian-med/2011/03/msg00025.html -- 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/20110303082753.gb9...@an3as.eu
Re: Lintian check for missing desktop files?
On Thu, 3 Mar 2011 09:27:53 +0100 Andreas Tille andr...@an3as.eu wrote: as I explained on Debian Med list[1] the existence of a desktop file is nearly as relevant as a manpage for a good user experience for users who are not that addicted to the command line as most of us are. I have not made any stats how many packages with applications which deserve a desktop file to show up in UIs implementing the freedesktop.org specification but I think I'm not wrong if I roughly estimate it with below 50%. In cases like this a lintian check has leaded to interesting results (see missing manpage). While I'm not a lintian expert I'd consider the following criterion as reasonable for a check * package has a file in /usr/bin * package name does not match '^lib' or '-doc$' * package has dependencies from typical libraries for freedesktop.org implementing interfaces which are for instance - libgnome2-0 - libkdeui5 - libxfce4ui-1-0 - libgtk-3-0 - libqtgui4 - ... Please excuse if my choice of the libraries is not optimal - I'm not an expert in this field but I hope you get the idea. * No file /usr/share/applications/*.desktop in the package If all these criterions are fullfilled a lintian warning about a missing desktop file could (should (!) IMHO) be issued. What happened to the idea that debian/menu files can be converted to desktop files, maybe not during package build but as a tool for maintainers? Do we have any idea how many packages would trigger this new check? (and how many of those do have debian/menu files?) My particular concern is that debian/menu is not as easily translatable as desktop files. The title displayed in whatever menu is used should always be translatable IMHO. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpBE3kmFon7E.pgp Description: PGP signature
Re: Lintian check for missing desktop files?
On Thu, Mar 03, 2011 at 10:18:58AM +, Neil Williams wrote: What happened to the idea that debian/menu files can be converted to desktop files, maybe not during package build but as a tool for maintainers? The idea is as good as its implementation proceeds. :-) IMHO a tool for maintainers would be appropriate for this problem. Regarding the lintian check the criterion menu-file-but-no-desktop-file could make sense as well. Do we have any idea how many packages would trigger this new check? (and how many of those do have debian/menu files?) I have no idea about both numbers. I just have noticed that several packages in Debian Med maintenance are lacking a desktop file even if they would deserve one. Charles Plessy some years ago was quite active in providing those files. I assume that other fields might have similar coverage of desktop files. My particular concern is that debian/menu is not as easily translatable as desktop files. The title displayed in whatever menu is used should always be translatable IMHO. Yes. I fully agree. This is IMHO the strongest reason why I do not believe in automatic conversion menu - desktop. Kind regards Andreas. -- 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/20110303134635.gf9...@an3as.eu
Re: Lintian check for missing desktop files?
On Thu, 2011-03-03 at 14:46 +0100, Andreas Tille wrote: On Thu, Mar 03, 2011 at 10:18:58AM +, Neil Williams wrote: What happened to the idea that debian/menu files can be converted to desktop files, maybe not during package build but as a tool for maintainers? The idea is as good as its implementation proceeds. :-) IMHO a tool for maintainers would be appropriate for this problem. Regarding the lintian check the criterion menu-file-but-no-desktop-file could make sense as well. [...] I think it's crazy to expect maintainers to provide both menu and desktop files for everything. That information should be provided once only, in whichever format is the more expressive (I think that would be desktop files, possibly with some Debian-specific extensions). Triggers and per-WM hooks should take care of any conversion required at installation time. Let's make that a release goal for wheezy instead of perpetuating these parallel menu systems. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Lintian check for missing desktop files?
On Thu, Mar 03, 2011 at 02:36:43PM +, Ben Hutchings wrote:
I think it's crazy to expect maintainers to provide both menu and
desktop files for everything. That information should be provided once
only, in whichever format is the more expressive (I think that would be
desktop files, possibly with some Debian-specific extensions). Triggers
and per-WM hooks should take care of any conversion required at
installation time. Let's make that a release goal for wheezy instead of
perpetuating these parallel menu systems.
ACK on the de-duplication (although I don't know whether they are in
fact more expressive than current Debian menu files). Another argument
for desktop files are that we have seen initiatives (e.g. AppStream)
which are going to rely on desktop files to identify common cross-distro
components. Pushing for desktop files, in collaboration with our
upstream, would also be a way of being good citizens helping with their
diffusion.
It doesn't seem to me that your proposal of making it a release goal for
Wheezy is incompatible with Andreas' proposal. Bottom line: a lintian
check would be a first useful step (the heuristic is clearly more
debatable, but I'm no condition to propose one which is better than the
one proposed by Andreas).
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Re: Lintian check for missing desktop files?
On 2011-03-03, Ben Hutchings b...@decadent.org.uk wrote: I think it's crazy to expect maintainers to provide both menu and desktop files for everything. That information should be provided once only, in whichever format is the more expressive (I think that would be desktop files, possibly with some Debian-specific extensions). Triggers my impression is that they express the same. there is a difference in the categories (sections) that doesn't make it fully possible to map completely in any direction. for example in games, in debian menu system we have and Games/Action, which contains actions and arcade games, and the FDO menu has ActionGame and ArcadeGame There can be found similar examples for 'the other way' There is a desktop2menu script in devscript that tries to do the conversion as good as possible, and per-WM hooks should take care of any conversion required at installation time. Let's make that a release goal for wheezy instead of perpetuating these parallel menu systems. Down with the debian menu! Long live the fdo menu. (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) /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/slrnimvce9.rvp.nos...@sshway.ssh.pusling.com
Re: Lintian check for missing desktop files?
On 03/03/11 15:17, Stefano Zacchiroli wrote: It doesn't seem to me that your proposal of making it a release goal for Wheezy is incompatible with Andreas' proposal. Bottom line: a lintian check would be a first useful step (the heuristic is clearly more debatable, but I'm no condition to propose one which is better than the one proposed by Andreas). Not sure if somebody has proposed it or not, but another heuristic would be whether there is a debian menu file but not a desktop file. Not saying it's better than Andreas' proposal... just another option. Emilio -- 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/4d6fbe00.3060...@debian.org
Re: Lintian check for missing desktop files?
Emilio Pozuelo Monfort po...@debian.org writes: Not sure if somebody has proposed it or not, but another heuristic would be whether there is a debian menu file but not a desktop file. Lintian intentionally doesn't do this because the Debian maintainers of the desktop systems in Debian didn't want lots of desktop entries for applications without a GUI, which often currently have menu entries. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87k4gg5dzr@windlord.stanford.edu
Re: Lintian check for missing desktop files?
Stefano Zacchiroli z...@debian.org writes: ACK on the de-duplication (although I don't know whether they are in fact more expressive than current Debian menu files). Desktop files are in general more expressive than menu files, and remaining missing features could be fairly easily added, I think. It doesn't seem to me that your proposal of making it a release goal for Wheezy is incompatible with Andreas' proposal. The main thing that has to happen to replace menu files with desktop files is to add an implementation of generation of menus from desktop files for those window managers and other menu clients that have Debian menu implementations but don't natively support desktop files. Otherwise, we have a regression in quality of menus for those applications. Last time we discussed this, fvwm2 was raised as a major example. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87fwr45dwz@windlord.stanford.edu
Re: Lintian check for missing desktop files?
Sune Vuorela nos...@vuorela.dk writes: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) Last time I checked fluxbox and awesome where both debian menu only as well. Regards Christoph pgpdyO38cMKdt.pgp Description: PGP signature
Re: Lintian check for missing desktop files?
On Thu, Mar 03, 2011 at 09:07:52AM -0800, Russ Allbery wrote: Emilio Pozuelo Monfort po...@debian.org writes: Not sure if somebody has proposed it or not, but another heuristic would be whether there is a debian menu file but not a desktop file. Lintian intentionally doesn't do this because the Debian maintainers of the desktop systems in Debian didn't want lots of desktop entries for applications without a GUI, which often currently have menu entries. Surely they can filter out entries with Terminal: true? 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/20110303225616.gi19...@decadent.org.uk
Re: Lintian check for missing desktop files?
On 2011-03-03, Christoph Egger christ...@debian.org wrote: --=-=-= Sune Vuorela nos...@vuorela.dk writes: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) Last time I checked fluxbox and awesome where both debian menu only as well. a quick search on google seems to tell that awesome does have xdg menu support. and another google search seems to tell about http://code.google.com/p/fluxbox-xdg-menu/ /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/slrnin07bq.rvp.nos...@sshway.ssh.pusling.com
Re: Lintian check for missing desktop files?
On Thu, 2011-03-03 at 23:01 +0100, Christoph Egger wrote: Sune Vuorela nos...@vuorela.dk writes: (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) Last time I checked fluxbox and awesome where both debian menu only as well. instead of letting the tail wag the dog then with menu2desktop, wouldn't it be better to cater to these WM's/DE's by providing a desktop2menu? Still would feel like adding more layers where they should be removed though... signature.asc Description: This is a digitally signed message part
Re: Lintian check for missing desktop files?
On Thu, Mar 03 2011, Sune Vuorela wrote: On 2011-03-03, Ben Hutchings b...@decadent.org.uk wrote: and per-WM hooks should take care of any conversion required at installation time. Let's make that a release goal for wheezy instead of perpetuating these parallel menu systems. Down with the debian menu! Long live the fdo menu. (isn't it only icewm and ratpoison and blackbox we might 'lose' by simply killing the debian menu) And fvwm, manoj -- Mirrors should reflect a little before throwing back images. Jean Cocteau Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/8739n3piac@anzu.internal.golden-gryphon.com
