Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Mon, Dec 15, 2003 at 01:54:13PM +0800, Cameron Patrick wrote: On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote: | Only GNOME applications should be in the GNOME Applications menu. Why?! Yea, I thought that was somewhat odd. The only reason the non KDE items are better integrated into the current KDE menu is due to technical limitations. I expect to be able to do it better when KDE converts fully to the standard (KDE 3.2) like Gnome currently has. Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Mon, 2003-12-15 at 05:54, Cameron Patrick wrote: On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote: | Only GNOME applications should be in the GNOME Applications menu. Why?! Rationale (and a real-world example): Both KDE and GNOME are attempting to make a completely self-integrated desktop environment, each have their own (often totally different) interface guidelines as well as different look and feels. Now, take a local library who have 20 machines all running Linux, with user accounts available to all who want them. The administrators can currently install both KDE and GNOME and allow users to choose which they prefer, perhaps leaving GNOME as the default due to its easier to use[0] interface. When using GNOME they see only GNOME applications in the GNOME menu, which is as it should be. In fact, the GNOME menu is fairly tightly controlled upstream to improve the ease of use. When using KDE they only see KDE applications, again as it should be. To cross-pollute the environments just creates a mess that won't buy you any friends with the administrator or their users. The applications don't look the same and don't work the same, welcome to interface hell. The current situation with everything else available on the Debian menu works perfectly, each environment has their own menu with everything else available if someone really wants to go looking for it. This can even be disabled. By all means choose a different format for the menu entries, but don't start sticking KDE applications in the GNOME menu, they aren't part of that Desktop Environment. Or a technical reason: starting a simple KDE application under GNOME requires around 60MB of memory, as many of the KDE services need to be started as well. The reverse is (I imagine) equally true. Don't cross-pollute the two desktop environments, they're fine as they are. Scott [0] in the administrator's view, anyway -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Chris Cheney wrote: On Fri, Dec 12, 2003 at 12:28:29PM +0800, Cameron Patrick wrote: The Categories= field (to place .desktop files into menu hierarchies) is AFAIK not used at all by KDE, although I think Gnome may support it. The above statements are probably true of KDE 3.1 since it doesn't use the proper /usr/share/applications layout. KDE 3.2 which is due to be released in about a month does use it. The location Gnome uses is correct. In addition the SuSE KDE packages in SuSE-9.0 are 3.1.4 with a backport of the XDG menues. So if you use SuSE, you already have the same menue in both DEs. -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, 13 Dec 2003, Billy Biggs wrote: Bruce Sass ([EMAIL PROTECTED]): The above is just the tip of the iceberg with respect to i18n, I had roughly the same size savings when I was removing translations from KDE2 files---KDE3 has more files, more translations per file, and I haven't looked at Gnome. Bruce, I can't figure out your position on i18n. Do you think that: 1. Debian should only provide english no 2. Menu entries should be english only no 3. Packages should individually only include one language no 4. Packages should include all languages, but only install files pertinent to the local language s/local language/languages the sysadmin wants installed/ ideally, installing then removing unwanted files is probably more practicable though. 5. Something else I don't think so I am just curious because I find your opinion puzzling. None of this has anything to do with .desktop vs menufile. If i18n support were added to menufile it would be the same. I prefer the .desktop format, but just switching to it will immediately drag in the translations... is this not the best time to address the issue? - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 2003-12-02 at 22:50, AKL. Mantas Kriauciunas wrote: Debian has a usability problem - it's hard to start lots of programs, installed from debian packages, because simple users just can't find them in menu. Standart debian menu entry isn't good solution for user-friendly desktops, like Gnome and KDE, because debian menu isn't intuitive (for example there are no icons for categories) and there are no possibility to translate debian menu entry. Leaping in late, without reading any other post in this thread :-) Only GNOME applications should be in the GNOME Applications menu. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Mon, Dec 15, 2003 at 04:07:56AM +, Scott James Remnant wrote: | Only GNOME applications should be in the GNOME Applications menu. Why?! Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 05:47:17PM -0700, Bruce Sass wrote: On Fri, 12 Dec 2003, Chris Cheney wrote: On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: ... .desktop files are not bloated... period. They include i18n which for you is bloat since you obviously can communicate in English. not bloated... period, yet you admit the translations are bloat for someone who doesn't need them. Can you also accept the X-KDE-* stuff is bloat for every menu data consumer except KDE (ditto for Gnome specials), and that in general freedesktop features are bloat for everyone who doesn't support the freedesktop standard. Bloat is relative, since i18n is needed by a large amount of people, certainly more than need english it is not really bloat. Certainly it isn't bloat for the 5Bil+ people whose language isn't english. Something you might determine is a critical feature someone else might consider bloat. Yes, X-KDE-* could be considered to be bloat by some people. However, the same people who have systems fast enough to actually run Gnome or KDE also have large enough hard drives that it shouldn't even be a consideration. Across all desktop files in the archive that probably amounts to less than 100KB of additional space. Bitching about a loss of 100KB when the same packages overall take 500MB+ is very petty. And no I do not think that the freedesktop standard overall is bloat. As I mentioned further down in this message Konqueror only uses 159 bytes when all i18n is stripped from it. I see many debian menu files that are larger than this and they don't contain i18n either. I suspect those files contain more than one menu entry; KDE has a file per entry, menu uses a file per package which contain multiple menu entries. Yes that is true, so I went and got the konqueror menu file to compare. Just the one entry for the file browser which is equivalent to the .desktop file is bigger than the .desktop file without its i18n support. And add to that the fact that the .menu description is shorter which further disproves the point that .desktop files are larger. .desktop - 159 bytes [Desktop Entry] Encoding=UTF-8 Type=Application Exec=kfmclient openProfile webbrowsing Icon=konqueror DocPath=konqueror/index.html Name=Konqueror Web Browser .menu - 168 bytes ?package(konqueror):\ needs=X11\ section=Apps/Net\ hints=KDE,Web browsers\ kderemove=y\ title=Konqueror\ command=/usr/bin/konqueror --profile webbrowsing If several KDE and Gnome developers got together and rewrote the menu-methods for the various WM's would that satisfy you? No, because it doesn't address the primary concern of (say) a Fluxbox user needing to process the KDE, Gnome, and freedesktop stuff which they don't have a use for. I contend that the processing the time difference would not be sufficient to tell the difference over extracting and installing packages on the system. And the only time menus get rebuilt normally is when you are installing new packages. Systems old enough to worry about this also typically don't have hundreds of menu files to deal with as well since their hd's are too small. As someone else stated regenerating all the menu files included with KDE (which is several hundred iirc) takes less than 10s on an Athlon 600, which is about a 5 year old system. 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; what percentage of resources that takes depends on the system... it may be a drop in the bucket for KDE and Gnome users, who are likely to have very capable machines, but what about those who don't have the resources to run KDE or Gnome---why should they be stuck with processing useless stuff they likely can't afford and obviously don't want? The entire menu hierarchy is regenerated everytime a package containing a menu entry is installed or removed. I call bullshit on this one. desktop files with no i18n are not several thousand bytes _pre_entry_. And the fact that those other WM's don't support should be considered a bug not a feature... For example the Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as we suggested earlier the Debian menu format gain i18n support then it would be just as big as .desktop (probably actually since Debian has very limited i18n support). Ok, the .desktop file sizes are typically between 1 and 2K---but you don't have to look too hard to find 3 or 4K .desktop files, and some of the (admitedly KDE specific) files are over 10K. Yup, that last bit is FUD: I fear it is the future of .desktop files, I'm uncertain they are atypical, and I doubt that 1-2K will be the norm... especially since the example (/usr/share/applnk/konqueror.desktop) you are holding up is 3748 bytes and incomplete (only 7 Name and over 3 dozen Comment items) on my box (unstable, updated daily). I took a look at one of these huge .desktop files, without i18n
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Cameron Patrick wrote: On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote: | This is not true. Almost all features are being used in current KDE and | to some degree by current GNOME. Could you please give examples? The Categories= field (to place .desktop files into menu hierarchies) is AFAIK not used at all by KDE, although I think Gnome may support it. The freedesktop 'menu' standard (where sub-menus can be generated from the categories in the .desktop files, and which also claims to allow legacy menus to be merged with the new standard) doesn't seem to have been adopted yet by anyone. It is supported and used in KDE-3.2beta. KDE-3.2 should be released in January. The worst part, though, is that currently both KDE and Gnome store their .desktop files in different places, so that a .desktop that is available to KDE (and placed in /usr/lib/applnk) won't automatically appear in the Gnome menu, which looks in /usr/lib/applications. I presume that these things are being worked on in later releases of KDE and Gnome, but I don't know where to look for the current status of their adoption of the freedesktop.org standards. Again, please have a look at KDE-3.2. I am currently using the KDE CVS debian snapshots. KDE stores all it's desktop files in /usr/share applications and GNOME uses the same directory. Of course the system can and will be improved, once it is generally adopted. I have also noticed what might be considered as 'abuse' of these standards, presumably due to poor implementation of some fields. For example, /usr/share/applications/epiphany.desktop lists its Name as Web Browser; it should more correctly list its name as Epiphany and have a GenericName field containing Web Browser. Not all desktop files are perfect yet. Especially those not part of the DE. But this should not be fixed downstream.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 01:11:12PM +0100, Moritz Moeller-Herrmann wrote: | It is supported and used in KDE-3.2beta. KDE-3.2 should be released in | January. [...] | Again, please have a look at KDE-3.2. I am currently using the KDE CVS | debian snapshots. KDE stores all it's desktop files in /usr/share | applications and GNOME uses the same directory. Woo, good to hear it! I stand corrected, then. :-) Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 12 Dec 2003, Chris Cheney wrote: On Fri, Dec 12, 2003 at 05:47:17PM -0700, Bruce Sass wrote: On Fri, 12 Dec 2003, Chris Cheney wrote: On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: ... .desktop files are not bloated... period. They include i18n which for you is bloat since you obviously can communicate in English. not bloated... period, yet you admit the translations are bloat for someone who doesn't need them. Can you also accept the X-KDE-* stuff is bloat for every menu data consumer except KDE (ditto for Gnome specials), and that in general freedesktop features are bloat for everyone who doesn't support the freedesktop standard. Bloat is relative, since i18n is needed by a large amount of people, certainly more than need english it is not really bloat. Certainly it isn't bloat for the 5Bil+ people whose language isn't english. Something you might determine is a critical feature someone else might consider bloat. Do the 5Bil+ people need all the translations, or just the few they understand/use. Should one or two someone's critical feature be imposed on the entire population. Yes, X-KDE-* could be considered to be bloat by some people. However, the same people who have systems fast enough to actually run Gnome or KDE also have large enough hard drives that it shouldn't even be a consideration. Unfortunately, the proposal as I understand it would have everyone getting the X-KDE-* and other specials... even though they may not have the space or processing power to run KDE. Across all desktop files in the archive that probably amounts to less than 100KB of additional space. Bitching about a loss of 100KB when the same packages overall take 500MB+ is very petty. And no I do not think that the freedesktop standard overall is bloat. Your figures are inaccurate. Based on your own numbers (and being somewhat generous in your favour): Let's say the average i18n-ed .desktop file is 2k, and a non-i18n file is 200 bytes, and there are 2625 of them in the archive... that is 5250k of i18n files and 513k of single language files, a difference of way more than less than 100KB. The above is just the tip of the iceberg with respect to i18n, I had roughly the same size savings when I was removing translations from KDE2 files---KDE3 has more files, more translations per file, and I haven't looked at Gnome. As I mentioned further down in this message Konqueror only uses 159 bytes when all i18n is stripped from it. I see many debian menu files that are larger than this and they don't contain i18n either. I suspect those files contain more than one menu entry; KDE has a file per entry, menu uses a file per package which contain multiple menu entries. Yes that is true, so I went and got the konqueror menu file to compare. Just the one entry for the file browser which is equivalent to the .desktop file is bigger than the .desktop file without its i18n support. And add to that the fact that the .menu description is shorter which further disproves the point that .desktop files are larger. .desktop - 159 bytes [Desktop Entry] Encoding=UTF-8 Type=Application Exec=kfmclient openProfile webbrowsing Icon=konqueror DocPath=konqueror/index.html Name=Konqueror Web Browser .menu - 168 bytes ?package(konqueror):\ needs=X11\ section=Apps/Net\ hints=KDE,Web browsers\ kderemove=y\ title=Konqueror\ command=/usr/bin/konqueror --profile webbrowsing nitpicking The 15 bytes used by the KDE specific kderemove line would not be necessary if menues are built from a common data pool (.desktop-159, .menu-153). Also, where is the Comment in the .desktop example. /nitpicking I don't see this comparison as meaningful, and even if I did, not significant because the size difference between the two formats is probably somewhere around the margin of error. If several KDE and Gnome developers got together and rewrote the menu-methods for the various WM's would that satisfy you? No, because it doesn't address the primary concern of (say) a Fluxbox user needing to process the KDE, Gnome, and freedesktop stuff which they don't have a use for. I contend that the processing the time difference would not be sufficient to tell the difference over extracting and installing packages on the system. And the only time menus get rebuilt normally is when you are installing new packages. Systems old enough to worry about this also typically don't have hundreds of menu files to deal with as well since their hd's are too small. I've hung a 30G drive off the bus of a 50MHz box, but that is besides the point... which is: the proposal gets everyone significantly larger than necessary menu data files, and everyone includes those who can't afford or don't want a freedesktop based box. As someone else stated regenerating all the menu files included with KDE (which is several hundred iirc)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 12 Dec 2003, Moritz Moeller-Herrmann wrote: ... Of course the system can and will be improved, once it is generally adopted. Improving it at the outset will speed up its adoption.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Bruce Sass ([EMAIL PROTECTED]): The above is just the tip of the iceberg with respect to i18n, I had roughly the same size savings when I was removing translations from KDE2 files---KDE3 has more files, more translations per file, and I haven't looked at Gnome. Bruce, I can't figure out your position on i18n. Do you think that: 1. Debian should only provide english 2. Menu entries should be english only 3. Packages should individually only include one language 4. Packages should include all languages, but only install files pertinent to the local language 5. Something else I am just curious because I find your opinion puzzling. None of this has anything to do with .desktop vs menufile. If i18n support were added to menufile it would be the same. -Billy
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, Dec 11, 2003 at 09:08:38PM +, Andrew Suffield wrote: On Wed, Dec 10, 2003 at 10:29:24PM -0800, Marc Wilson wrote: On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: We don't have to map them onto anything. We just have to pass them through to the menu methods in a fashion that allows them to generate .desktop files. Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. You seem to have lost the context. Not at all. You want to enforce on $RANDOM_UPSTREAM the idea that they have to support .desktop files. That is *not* going to work. Debian does not have that sort of power. On the other hand, the idea that an application desiring to participate in the menu system being required to provide the necessary menu-method to get from .desktop files to their own format is much more reasonable. Upstream can create that, or the package maintainer can, or the menu package can provide it. Boy... that sure sounds a lot like the current $APPLICATION-agnostic method Debian has right now. So, why does this change need to happen again? If what you want is for only Gnome and KDE to be able to participate in the menu system, you could just come out and say so. -- Marc Wilson | All kings is mostly rapscallions. --Mark Twain [EMAIL PROTECTED] | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 2003-12-12 at 01:01, Marc Wilson wrote: Not at all. You want to enforce on $RANDOM_UPSTREAM the idea that they have to support .desktop files. That is *not* going to work. Debian does not have that sort of power. On the other hand, the idea that an application desiring to participate in the menu system being required to provide the necessary menu-method to get from .desktop files to their own format is much more reasonable. Upstream can create that, The above two paragraphs don't make sense to me, in combination. If upstream can write code to convert from .desktop to their own format, why can't they just include that directly in their software? The user would never have to know that the software wasn't reading .desktop natively (except that presumably it wouldn't support all the .desktop features). signature.asc Description: This is a digitally signed message part
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Marc Wilson dijo [Thu, Dec 11, 2003 at 10:01:39PM -0800]: Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. You seem to have lost the context. Not at all. You want to enforce on $RANDOM_UPSTREAM the idea that they have to support .desktop files. That is *not* going to work. Debian does not have that sort of power. Worse yet - after demanding that, we probably will rewrite their .desktop files - We will still (I hope) strive to provide menus consistent with our way of doing things. One of the main roles of the maintainers of a distribution is to handle interaction between each individual package and the rest of the collection - this involves sorting out how menus will be presented. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 04:05:50AM +0100, Moritz Moeller-Herrmann wrote: Because nobody but KDE and Gnome use those features and they already support .desktop files. How would e.g. the lyx debian package get an i18nized menu entry into the menu of either KDE or Gnome. YOU HAVE TO PROVIDE A DESKTOP FILE IF YOU WANT A DECENT MENU. FUD. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, Dec 11, 2003 at 10:01:39PM -0800, Marc Wilson wrote: On Thu, Dec 11, 2003 at 09:08:38PM +, Andrew Suffield wrote: On Wed, Dec 10, 2003 at 10:29:24PM -0800, Marc Wilson wrote: On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: We don't have to map them onto anything. We just have to pass them through to the menu methods in a fashion that allows them to generate .desktop files. Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. You seem to have lost the context. Not at all. You want to enforce on $RANDOM_UPSTREAM the idea that they have to support .desktop files. That is *not* going to work. Debian does not have that sort of power. Eh? That's the opposite of what I've been saying all along. I think you have lost the context. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 11:42:25AM -0600, Gunnar Wolf wrote: Worse yet - after demanding that, we probably will rewrite their .desktop files - We will still (I hope) strive to provide menus consistent with our way of doing things. One of the main roles of the maintainers of a distribution is to handle interaction between each individual package and the rest of the collection - this involves sorting out how menus will be presented. All that would do is make it consitently different from all other distributions. Assuming that they listed the proper Categories in their Categories: section all that would be needed, if we wanted to be different from other dists, is tweaking of how to break out the menu hierarchy. It would not involve any modification of the .desktop files themselves. See section A. http://www.freedesktop.org/standards/menu-spec/menu-spec-0.8.html Chris Cheney signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: On Tue, 9 Dec 2003, Henning Makholm wrote: Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: In which format shall application packages store their menu information. It doesn't matter, If you don't think the problem being discussed matters, why are you participating in the discussion? The problem is real, the format used to convey the data is immaterial. the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. Yes. relatively small change vs. rewriting almost from scratch NIH. Users and developers propose following the freedesktop standard and using this. Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. The pain is not worth the gain... why should all the menu consumers need to redo their menu handling so two of them can have a slightly easier time of it. Or just let the Gnome and KDE people who want this do the rewrite for the others. How is this logical? How does the freedesktop standard not gain us features? Because nobody but KDE and Gnome use those features and they already support .desktop files. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. Ok. How about doing it so the vast majority of menu consumers are not stuck with a needless rewrite. See above... freedesktop entry features debian menu file features True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. All users should be able to get what they want, including those who don't want KDE or Gnome... saddling them with bloated .desktop files does not achieve that. .desktop files are not bloated... period. They include i18n which for you is bloat since you obviously can communicate in English. As I mentioned further down in this message Konqueror only uses 159 bytes when all i18n is stripped from it. I see many debian menu files that are larger than this and they don't contain i18n either. Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. Yes, but they would benefit in the same way if the KDE and Gnome specific bits were an addendum to the main menu data entries. Only KDE and Gnome users stand to benefit, so they should be the ones with the added burden. If several KDE and Gnome developers got together and rewrote the menu-methods for the various WM's would that satisfy you? I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; what percentage of resources that takes depends on the system... it may be a drop in the bucket for KDE and Gnome users, who are likely to have very capable machines, but what about those who don't have the resources to run KDE or Gnome---why should they be stuck with processing useless stuff they likely can't afford and obviously don't want? The entire menu hierarchy is regenerated everytime a package containing a menu entry is installed or removed. I call bullshit on this one. desktop files with no i18n are not several thousand bytes _pre_entry_. And the fact that those other WM's don't support should be considered a bug not a feature... For example the Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as we suggested earlier the Debian menu format gain i18n support then it would be just as big as .desktop (probably actually since Debian has very limited i18n support). I would like to see: /usr/lib/menu/desktop /usr/lib/menu/desktop/gnome /usr/lib/menu/desktop/kde etc. desktop/ can contain the
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 12:28:29PM +0800, Cameron Patrick wrote: On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote: | Cameron Patrick wrote: | | On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | | | Because you gain *nothing* | | | | Are you claiming that everyone who says that .desktop has technical | | advantages is a liar? These features actually do not exist in the | | desktop format? (It may be so; I have no firsthand information, but it | | does sound far out). | | Most of the advantages of .desktop that I am aware of are currently | vapourware - i.e. they're in the specs on the freedesktop.org site, but | not yet implemented in KDE and Gnome. | | This is not true. Almost all features are being used in current KDE and to | some degree by current GNOME. Could you please give examples? The Categories= field (to place .desktop files into menu hierarchies) is AFAIK not used at all by KDE, although I think Gnome may support it. The freedesktop 'menu' standard (where sub-menus can be generated from the categories in the .desktop files, and which also claims to allow legacy menus to be merged with the new standard) doesn't seem to have been adopted yet by anyone. The worst part, though, is that currently both KDE and Gnome store their .desktop files in different places, so that a .desktop that is available to KDE (and placed in /usr/lib/applnk) won't automatically appear in the Gnome menu, which looks in /usr/lib/applications. I presume that these things are being worked on in later releases of KDE and Gnome, but I don't know where to look for the current status of their adoption of the freedesktop.org standards. The above statements are probably true of KDE 3.1 since it doesn't use the proper /usr/share/applications layout. KDE 3.2 which is due to be released in about a month does use it. The location Gnome uses is correct. I have also noticed what might be considered as 'abuse' of these standards, presumably due to poor implementation of some fields. For example, /usr/share/applications/epiphany.desktop lists its Name as Web Browser; it should more correctly list its name as Epiphany and have a GenericName field containing Web Browser. I've already reported that, several months ago, to some Gnome people in #debian-devel, hopefully it will be fixed soon. Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Daniel Burrows ([EMAIL PROTECTED]): On Fri, Dec 12, 2003 at 04:11:08PM -0600, Chris Cheney [EMAIL PROTECTED] was heard to say: All that would do is make it consitently different from all other distributions. Assuming that they listed the proper Categories in their Categories: section all that would be needed, if we wanted to be ^ Isn't that a rather large assumption? The .desktop format is nice in that there are tools to manipulate the files [1] so changing this in the packaging is pretty clean. -Billy [1] http://www.freedesktop.org/Software/desktop-file-utils
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 04:11:08PM -0600, Chris Cheney [EMAIL PROTECTED] was heard to say: All that would do is make it consitently different from all other distributions. Assuming that they listed the proper Categories in their Categories: section all that would be needed, if we wanted to be ^ Isn't that a rather large assumption? Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | Almost Winter, Winter, Still Winter, and Construction.| \- The Turtle Moves! -- http://www.lspace.org /
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 12 Dec 2003, Chris Cheney wrote: On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: ... .desktop files are not bloated... period. They include i18n which for you is bloat since you obviously can communicate in English. not bloated... period, yet you admit the translations are bloat for someone who doesn't need them. Can you also accept the X-KDE-* stuff is bloat for every menu data consumer except KDE (ditto for Gnome specials), and that in general freedesktop features are bloat for everyone who doesn't support the freedesktop standard. As I mentioned further down in this message Konqueror only uses 159 bytes when all i18n is stripped from it. I see many debian menu files that are larger than this and they don't contain i18n either. I suspect those files contain more than one menu entry; KDE has a file per entry, menu uses a file per package which contain multiple menu entries. ... If several KDE and Gnome developers got together and rewrote the menu-methods for the various WM's would that satisfy you? No, because it doesn't address the primary concern of (say) a Fluxbox user needing to process the KDE, Gnome, and freedesktop stuff which they don't have a use for. ... 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; what percentage of resources that takes depends on the system... it may be a drop in the bucket for KDE and Gnome users, who are likely to have very capable machines, but what about those who don't have the resources to run KDE or Gnome---why should they be stuck with processing useless stuff they likely can't afford and obviously don't want? The entire menu hierarchy is regenerated everytime a package containing a menu entry is installed or removed. I call bullshit on this one. desktop files with no i18n are not several thousand bytes _pre_entry_. And the fact that those other WM's don't support should be considered a bug not a feature... For example the Konqueror .desktop file is 159 bytes with no i18n or 2234 with it. If as we suggested earlier the Debian menu format gain i18n support then it would be just as big as .desktop (probably actually since Debian has very limited i18n support). Ok, the .desktop file sizes are typically between 1 and 2K---but you don't have to look too hard to find 3 or 4K .desktop files, and some of the (admitedly KDE specific) files are over 10K. Yup, that last bit is FUD: I fear it is the future of .desktop files, I'm uncertain they are atypical, and I doubt that 1-2K will be the norm... especially since the example (/usr/share/applnk/konqueror.desktop) you are holding up is 3748 bytes and incomplete (only 7 Name and over 3 dozen Comment items) on my box (unstable, updated daily). ... desktop/ can contain the generic .desktop data (translations and features common to all .desktop aware menu consumers), the gnome and kde dirs would contain the bits specific to them (X-KDE-*, etc.) Hahaha, you do realize how much extra effort that would entail? It would be much simpler for the Gnome and KDE maintainers to just rewrite all the converters and the menu package itself than to keep that up to date. Maybe I don't (although nobody has torn apart my most recent post regarding the scheme)... please enlighten me. - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 06:33:52PM -0500, Daniel Burrows wrote: On Fri, Dec 12, 2003 at 04:11:08PM -0600, Chris Cheney [EMAIL PROTECTED] was heard to say: All that would do is make it consitently different from all other distributions. Assuming that they listed the proper Categories in their Categories: section all that would be needed, if we wanted to be ^ Isn't that a rather large assumption? If they aren't in the proper categories as listed by the standard it should be treated as any other bug and be corrected. That won't be the common case, and we can just write the convertor to look for the standardized categories. Chris signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 09:37:51AM -0500, Colin Walters wrote: On Fri, 2003-12-12 at 01:01, Marc Wilson wrote: Not at all. You want to enforce on $RANDOM_UPSTREAM the idea that they have to support .desktop files. That is *not* going to work. Debian does not have that sort of power. On the other hand, the idea that an application desiring to participate in the menu system being required to provide the necessary menu-method to get from .desktop files to their own format is much more reasonable. Upstream can create that, The above two paragraphs don't make sense to me, in combination. The rest of the second paragraph, which you clipped, make it plain that what I was doing was listing sources for the .desktop file-converting-menu-method. It could be provided by upstream, it could be created by the Debian package maintainer, it could be part of the menu package. In short, it could be created by just about anyone. If upstream can write code to convert from .desktop to their own format, why can't they just include that directly in their software? Perhaps THEY don't want to, but do want to allow their software to participate in the Debian menu system. It would be their choice, one way, or the other. -- Marc Wilson | Debian Hint #7: You can use the cron-apt package [EMAIL PROTECTED] | to do automatic nightly downloads of updates for | packages installed on your system. signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: We don't have to map them onto anything. We just have to pass them through to the menu methods in a fashion that allows them to generate .desktop files. Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. Like just about any system other than KDE or Gnome. -- Marc Wilson | The mome rath isn't born that could outgrabe me. [EMAIL PROTECTED] | -- Nicol Williamson signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 2003-12-11 at 05:08, Dagfinn Ilmari Mannsker wrote: localepurge - Automagically removing unnecessary locale data From localepurge README.Debian: ** Please note, that this tool is a hack which is *not* integrated with Debian's package management system and therefore is not for the faint of heart. ... I sincerely hope that some day further development of Debian's great package management system will make localepurge fully obsolete. btw, Total disk space freed by localepurge: 180284K -- Isaac Clerencia | Using Debian GNU/Linux | JID: [EMAIL PROTECTED] Alternativas libres :: http://alts.homelinux.net Mi bitacora :: http://barrapunto.com/~guacamayo/bitacora Please encrypt your messages when e-mailing me, GPG ID: 54E672DE signature.asc Description: This is a digitally signed message part
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Isaac Clerencia [EMAIL PROTECTED] writes: I sincerely hope that some day further development of Debian's great package management system will make localepurge fully obsolete. Yes, there are plans for a generic install-time file exclusion mechanism in dpkg, according to Adam Heath (head dpkg hacker) on IRC today. btw, Total disk space freed by localepurge: 180284K Feels good, doesn't it? -- ilmari
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 10:29:24PM -0800, Marc Wilson wrote: On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: We don't have to map them onto anything. We just have to pass them through to the menu methods in a fashion that allows them to generate .desktop files. Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. You seem to have lost the context. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass [EMAIL PROTECTED] On Wed, 10 Dec 2003, Henning Makholm wrote: Have you quantified the bloat you are speaking about? Can the same argument not apply to any i18n effort? Yes, using KDE2. The script removed any lines with [stuff] in them from KDE files (was possible at the time without incurring breakage) Then it's not the format you're opposing, but the inclusion of extra content in the .debs. -- Henning Makholm Monarki, er ikke noget materielt ... Borger!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Isaac Clerencia [EMAIL PROTECTED] I sincerely hope that some day further development of Debian's great package management system will make localepurge fully obsolete. brainstorm on I've been wondering whether the Right solution to this kind of problems might be to invent some concept of glue packages. In technical terms, that would be a way to tell apt-get and its ilk things like: - If frobnitz and locale-danish are both installed, then automatically try to install frobnitz-i18n-da. - If frobnitz and emacsen are both installed, then automatically try to install frobnitz-el. - If libx11 and tetex-base are both installed, then automatically try to install xdvi. - If ispell and locale-danish are both installed, then automatically try to install idanish. Then by installing appropriate locale-XXX packages, one would automatically pull in i18ns for the specified language for all packages that have been translated. Nobody would get bloated with translations of pacakges they don't use or translatations to languages they don't read. Most of the glue packages should be in a special section where they don't show up in package-selection interfaces. Possible exceptions would be things like idanish above - it's quite plausible to want Danish spell checking without also wanting one's tools in general to attempt to speak Danish in status and error messages. Since many glue packages will individually be quite small, some implementation engineering will be necessary in order to prevent bloat my maintainer scripts and standard /usr/share/doc/* contents. Some kind of by-demand distribution and assembly of Packages files might also be necessary in practise. /brainstorm -- Henning MakholmNej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield [EMAIL PROTECTED] wrote: On Wed, Dec 10, 2003 at 10:29:24PM -0800, Marc Wilson wrote: On Wed, Dec 10, 2003 at 12:31:17PM +, Andrew Suffield wrote: We don't have to map them onto anything. We just have to pass them through to the menu methods in a fashion that allows them to generate .desktop files. Other way around. You have to pass .desktop files through to the menu-methods in a fashion that allows them to generate menus digestible to applications not supporting .desktop files. You seem to have lost the context. Why, how? *If* Debian is supposed to switch to .desktop (instead of enhancing the Debian menu format) the only sensibl possibiltiy is to make menu be able to use .desktop as input. Once that is there any package can switch at its convenience (if it there are benefits for the package). The other possibilities (Throw away menu, dump all windownagers not supporting .desktop, implement .desktop support for all all windowmanagers) are imho clearly unrealistic. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 11 Dec 2003, Henning Makholm wrote: Scripsit Bruce Sass [EMAIL PROTECTED] On Wed, 10 Dec 2003, Henning Makholm wrote: Have you quantified the bloat you are speaking about? Can the same argument not apply to any i18n effort? Yes, using KDE2. The script removed any lines with [stuff] in them from KDE files (was possible at the time without incurring breakage) Then it's not the format you're opposing, but the inclusion of extra content in the .debs. Almost correct... I don't think it is appropriate, or fair, that those not using KDE or Gnome should need to deal with KDE/Gnome specific stuff when there are other options. The existing menu data format has a potential problem in that the entries could get too big (too long a line), so a different format wouldn't hurt and may even be a necessity at some point. A single label=value(s) per line, as is used with the freedesktop standard, should be able to handle any amount of menu data items and any reasonable number of values per item. (as you may have noticed) I have a problem with keeping all possible menu data items for an enty in one file. Splitting the menu entry data into generic, KDE, and Gnome 'bins' is a more complex solution than keeping everything in one file, but I don't think the computer cares (and programmers who can't handle it should probably not be doing system level infrastructure programming, eh). Since bloating packages by distributing the generic, KDE and Gnome bits in separate files is almost as bad as forcing all menu consumers to process one large file, it makes sense to distribute the data as one file in the .deb and split it up during installation. Splitting up an all inclusive menu data file into 'bins' should be relatively trivial: generic items go into /usr/lib/menu/package, X-KDE|GNOME-* items go into /usr/lib/menu/desktop/kde|gnome/package, everything else goes into /usr/lib/menu/desktop/package. The only coding needed would be: a program to install the menu data into the appropriate bins, and the KDE/Gnome menu-methods would need to look for more data when building their menues. Ideally, /usr/share/applications and /usr/share/applnk (and the Gnome equivalent) would either disappear or be generated... keeping them as installation targets makes it difficult, if not impossible, to provide system-wide overrides to the packaged menu data. - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Henning Makholm [EMAIL PROTECTED] Oops, possible meaning-disturbing typo: implementation engineering will be necessary in order to prevent bloat my maintainer scripts and standard /usr/share/doc/* contents. s/my/by/ -- Henning Makholm Det er du nok fandens ene om at mene. For det ligger i Australien!
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Bruce Sass wrote: On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: Freedesktop standard supporting systems are probably used by 90% of all Debian desktop users. Unsubstantial, and probably bullshit. Maybe you are just incapable of finding arguments and have to resort to bad language? Highly probable. Because nobody but KDE and Gnome use those features and they already support .desktop files. How would e.g. the lyx debian package get an i18nized menu entry into the menu of either KDE or Gnome. YOU HAVE TO PROVIDE A DESKTOP FILE IF YOU WANT A DECENT MENU. So your approach doubles the work for all people, because we now need two menue entry files. Onde freedesktop and one for Bruce. True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. How long does it take to strip a few information lines of let's exaggerate 6000 menu entries? Even a bash script on an old system wouldnt take long. Use perl and you won't even notice a delay. older - stability simpler - faster, less resources hungry nonstandard - less stable, more work for maintainers simpler - hardly a CPU speed problem on today's desktop machines, also e.g. KDE can process all the menu files it brings in about 10 secson an Athlon-600MHz. I don't understand how anyone can not support this change. Because: Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. Debian would profit. Debian users would have a complete menu. Maintainers would be able to use upstream information for the menue entries. also There is currently no way to provide system-wide alternates to the distributed .desktop files. Only having per-user customisation available really, really, sucks, imo. PArsing error? What is this problem? and I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? Jesus, how often do you update your fscking menus? thrice daily? -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Cameron Patrick wrote: On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | Because you gain *nothing* | | Are you claiming that everyone who says that .desktop has technical | advantages is a liar? These features actually do not exist in the | desktop format? (It may be so; I have no firsthand information, but it | does sound far out). Most of the advantages of .desktop that I am aware of are currently vapourware - i.e. they're in the specs on the freedesktop.org site, but not yet implemented in KDE and Gnome. This is not true. Almost all features are being used in current KDE and to some degree by current GNOME. Could you please give examples? -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 12, 2003 at 04:12:58AM +0100, Moritz Moeller-Herrmann wrote: | Cameron Patrick wrote: | | On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | | | Because you gain *nothing* | | | | Are you claiming that everyone who says that .desktop has technical | | advantages is a liar? These features actually do not exist in the | | desktop format? (It may be so; I have no firsthand information, but it | | does sound far out). | | Most of the advantages of .desktop that I am aware of are currently | vapourware - i.e. they're in the specs on the freedesktop.org site, but | not yet implemented in KDE and Gnome. | | This is not true. Almost all features are being used in current KDE and to | some degree by current GNOME. Could you please give examples? The Categories= field (to place .desktop files into menu hierarchies) is AFAIK not used at all by KDE, although I think Gnome may support it. The freedesktop 'menu' standard (where sub-menus can be generated from the categories in the .desktop files, and which also claims to allow legacy menus to be merged with the new standard) doesn't seem to have been adopted yet by anyone. The worst part, though, is that currently both KDE and Gnome store their .desktop files in different places, so that a .desktop that is available to KDE (and placed in /usr/lib/applnk) won't automatically appear in the Gnome menu, which looks in /usr/lib/applications. I presume that these things are being worked on in later releases of KDE and Gnome, but I don't know where to look for the current status of their adoption of the freedesktop.org standards. I have also noticed what might be considered as 'abuse' of these standards, presumably due to poor implementation of some fields. For example, /usr/share/applications/epiphany.desktop lists its Name as Web Browser; it should more correctly list its name as Epiphany and have a GenericName field containing Web Browser. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 11:47:28AM +0800, Cameron Patrick wrote: On Tue, Dec 09, 2003 at 09:49:25PM +, Andrew Suffield wrote: | Alternate approaches (that involve significantly less work) That's the bit that I (and presumably others) am not convinced about. You keep making this assertion, but with little to back it up. Have you, e.g., looked at the Categories definitions for .desktop files? I don't believe that mapping them onto the section field of our menu system (and vice versa) without losing any information would be trivial. We don't have to map them onto anything. We just have to pass them through to the menu methods in a fashion that allows them to generate .desktop files. We *may* be able to do more interesting things with them, but we don't *need* to. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 05:18:21PM -0600, Billy Biggs wrote: Andrew Suffield ([EMAIL PROTECTED]): On Tue, Dec 09, 2003 at 09:49:54AM -0600, Billy Biggs wrote: Andrew Suffield ([EMAIL PROTECTED]): It's pass a few more text fields through to the menu methods, and use them to generate .desktop files versus rewrite everything. You sure it's rewrite everything? A script to parse all .desktop files in /usr/share/applications and output the same as 'update-menus Straw man, again. The proposal was to rewrite all menu entries as .desktop files - yeah, I'm sure that means rewriting them all. Agreed on that, but it's not rewriting all of the menu package, which is what I felt your post implied. Did you miss the context I quoted? You've since deleted it; let's bring it back: ... You do realize that the desktop standard has more features than the ... debian menu system? Like i18n, icon theming, dynamic construction of a ... menu hierarchy based on user /Desktop system preferences and so on? And ... that this information would be lost? Why not run it the other way around, ... convert the existing debian menu entries to .desktop files and work from ... there? I think that this way would help debian on the desktops. [Ignoring most of the drivel, the second to last sentence is the relevant one; the rest of the mail I was replying to followed on from that] Rewriting all menu files is fairly trivial and does not have to be done all at once. Fairly trivial? I have over a hundred affected packages installed on this box alone. And... you do have to rewrite the menu package as well, obviously: A script to parse all .desktop files in /usr/share/applications and output the same as 'update-menus That's most of the interesting content of the menu package (plus documentation etc). It's not really a very complicated package. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Henning Makholm wrote: Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: In which format shall application packages store their menu information. It doesn't matter, If you don't think the problem being discussed matters, why are you participating in the discussion? The problem is real, the format used to convey the data is immaterial. the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. Yes. relatively small change vs. rewriting almost from scratch Users and developers propose following the freedesktop standard and using this. Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. The pain is not worth the gain... why should all the menu consumers need to redo their menu handling so two of them can have a slightly easier time of it. How is this logical? How does the freedesktop standard not gain us features? Because nobody but KDE and Gnome use those features and they already support .desktop files. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. Ok. How about doing it so the vast majority of menu consumers are not stuck with a needless rewrite. freedesktop entry features debian menu file features True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. All users should be able to get what they want, including those who don't want KDE or Gnome... saddling them with bloated .desktop files does not achieve that. Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. Yes, but they would benefit in the same way if the KDE and Gnome specific bits were an addendum to the main menu data entries. Only KDE and Gnome users stand to benefit, so they should be the ones with the added burden. I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; what percentage of resources that takes depends on the system... it may be a drop in the bucket for KDE and Gnome users, who are likely to have very capable machines, but what about those who don't have the resources to run KDE or Gnome---why should they be stuck with processing useless stuff they likely can't afford and obviously don't want? The entire menu hierarchy is regenerated everytime a package containing a menu entry is installed or removed. I would like to see: /usr/lib/menu/desktop /usr/lib/menu/desktop/gnome /usr/lib/menu/desktop/kde etc. desktop/ can contain the generic .desktop data (translations and features common to all .desktop aware menu consumers), the gnome and kde dirs would contain the bits specific to them (X-KDE-*, etc.) - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Henning Makholm wrote: Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: If you don't think the problem being discussed matters, why are you participating in the discussion? The problem is real, the format used to convey the data is immaterial. The format that should be used is what this thread is about discussing. If you want to discuss something different, that is fine, but it will be most practical if you do it in a different thread. the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. Yes. relatively small change vs. rewriting almost from scratch Nobody has proposed rewriting almost from scratch. Please avoid strawman arguments; they convince nobody of anything and does nothing to forward a resultion of the question. Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. The pain is not worth the gain... Nobody has put forward any description of which pain it is that you speak. why should all the menu consumers need to redo their menu handling It is not being proposed that they should. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. Ok. How about doing it so the vast majority of menu consumers are not stuck with a needless rewrite. They aren't. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. All users should be able to get what they want, including those who don't want KDE or Gnome... saddling them with bloated .desktop files does not achieve that. Have you quantified the bloat you are speaking about? Can the same argument not apply to any i18n effort? Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. Yes, but they would benefit in the same way if the KDE and Gnome specific bits were an addendum to the main menu data entries. At the cost of a more complicated system, which would by nobody anything. Only KDE and Gnome users stand to benefit, so they should be the ones with the added burden. Which burden? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; I think we can spare that much memory while generating the menus. I would like to see: /usr/lib/menu/desktop /usr/lib/menu/desktop/gnome /usr/lib/menu/desktop/kde But for some reason you're wildly opposed to the idea that .debs can contain files that populate these directories. Why? -- Henning Makholm Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, 10 Dec 2003, Henning Makholm wrote: Have you quantified the bloat you are speaking about? Can the same argument not apply to any i18n effort? Yes, using KDE2. The script removed any lines with [stuff] in them from KDE files (was possible at the time without incurring breakage) and would typically result in about 5M of disk usage being reduced to a couple hundred K. KDE was also faster processing and accessing its menues, although I did not quantify that aspect (not as easy to do and the difference was obvious enough that I didn't feel the need to hack KDE to put a number to it). Yes, the same argument applies to all i18n efforts. I18n is great, until disk usage and processing times start to climb with no real benefit to individual users. Yes, but they would benefit in the same way if the KDE and Gnome specific bits were an addendum to the main menu data entries. At the cost of a more complicated system, which would by nobody anything. I would hardly call avoiding forcing everyone except KDE and Gnome the need to deal with menu data files which are 10x to 20x the size they need to be `not buying nobody anything'. Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; I think we can spare that much memory while generating the menus. memory, disk space, and processing time Maybe you can spare it, I can't, and I suspect those trying to run a light weight system either can't or don't want to. I would like to see: /usr/lib/menu/desktop /usr/lib/menu/desktop/gnome /usr/lib/menu/desktop/kde But for some reason you're wildly opposed to the idea that .debs can contain files that populate these directories. Why? Huh, I think you need to do some re-reading. - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Wed, Dec 10, 2003 at 07:36:15PM -0700, Bruce Sass wrote: | Have you quantified the bloat you are speaking about? Can the same | argument not apply to any i18n effort? | | Yes, using KDE2. [...] | Yes, the same argument applies to all i18n efforts. | | I18n is great, until disk usage and processing times start to climb | with no real benefit to individual users. I seem to recall reading a number of complaints /from users/ in the BTS, requesting .desktop files precisely because they are i18nalised. Others have suggested expanding the current Debian menu definition to handle i18n. That, to me, sounds like there must be some kind of benefit to individual users to have translated menu items. | I would hardly call avoiding forcing everyone except KDE and Gnome the | need to deal with menu data files which are 10x to 20x the size they | need to be `not buying nobody anything'. I suspect that those who would rather see menu entries in their native language - and whose native language is not English - would consider the larger menu data files necessary to handle i18n to be a real advantage. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Cameron Patrick [EMAIL PROTECTED] writes: I seem to recall reading a number of complaints /from users/ in the BTS, requesting .desktop files precisely because they are i18nalised. Others have suggested expanding the current Debian menu definition to handle i18n. That, to me, sounds like there must be some kind of benefit to individual users to have translated menu items. Of course, but it's also clear that for many, _many_ people, having hebrew translations for everything is simply bloat. I'd think that ideally, there could be some system-wide setting that specified which languages to support (e.g. `english, french, korean'), and upon installation, i18nalised files would be filtered to strip out any `unsupported' languages. I suppose the default should probably be to keep all languages. -Miles -- 97% of everything is grunge
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Miles Bader [EMAIL PROTECTED] writes: I'd think that ideally, there could be some system-wide setting that specified which languages to support (e.g. `english, french, korean'), and upon installation, i18nalised files would be filtered to strip out any `unsupported' languages. I suppose the default should probably be to keep all languages. localepurge - Automagically removing unnecessary locale data -- ilmari
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: freedesktop entry features debian menu file features Therefore you can do a lossless transition from .desktop to menu, but not the other way around. It makes sense to use the .desktop standard. I know what you mean, but don't you mean lossless transition from menu to .desktop ? .desktop is the one that has more features, so a transition from .desktop to menu would lose. It's trivial but I might not understand the issues if its the opposite.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? [...] Because you gain *nothing* Are you claiming that everyone who says that .desktop has technical advantages is a liar? These features actually do not exist in the desktop format? (It may be so; I have no firsthand information, but it does sound far out). -- Henning Makholm Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield wrote: On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? And that this information would be lost? Why not run it the other way around, convert the existing debian menu entries to .desktop files and work from there? I think that this way would help debian on the desktops. Because you gain *nothing* and introduce a pointless transition. The question to solve is: In which format shall application packages store their menu information. Users and developers propose following the freedesktop standard and using this. Freedesktop standard supporting systems are probably used by 90% of all Debian desktop users. Now you say: No let's use the debian menu system, which only we use and which is not the default of any major WM. This means losing i18n, dynamic construction of menus and icon theming in 90 % of the desktop, because Debian menu items do not support these features. How is this logical? How does the freedesktop standard not gain us features? None of which is the problem of the menu package. It just has to read the fields and pass them to the methods, which then write out suitable data files for the frontend. In the case of kde/gnome, that would be a .desktop file; for everything else, yes, the data is thrown away. Nothing else supports those features, and this is again not our problem. freedesktop entry features debian menu file features Therefore you can do a lossless transition from .desktop to menu, but not the other way around. It makes sense to use the .desktop standard. Then those desktops who support it (KDE+Gnome+??) can use the desktop files directly. For other (older or simpler) desktops the debian menu system has to be adapted to use the .desktop files (addditionaly or instead of the menu files). I don't understand how anyone can not support this change. -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: | Because you gain *nothing* | | Are you claiming that everyone who says that .desktop has technical | advantages is a liar? These features actually do not exist in the | desktop format? (It may be so; I have no firsthand information, but it | does sound far out). Most of the advantages of .desktop that I am aware of are currently vapourware - i.e. they're in the specs on the freedesktop.org site, but not yet implemented in KDE and Gnome. However, since both KDE and Gnome developers helped to write the specs in question, it seems not altogether unreasonable to expect some kind of implementation of them in the future. Internationalisation is the big one that's here already, and IMHO should be added to the Debian menu system regardless of any outcome w.r.t. freedesktop. The relevant pages on the freedesktop.org site are: http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html Cameron.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield ([EMAIL PROTECTED]): It's pass a few more text fields through to the menu methods, and use them to generate .desktop files versus rewrite everything. You sure it's rewrite everything? A script to parse all .desktop files in /usr/share/applications and output the same as 'update-menus --stdout' seems pretty simple and sufficient. Am I wrong? -Billy
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: Andrew Suffield wrote: On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? And that this information would be lost? Why not run it the other way around, convert the existing debian menu entries to .desktop files and work from there? I think that this way would help debian on the desktops. Because you gain *nothing* and introduce a pointless transition. The question to solve is: In which format shall application packages store their menu information. Users and developers propose following the freedesktop standard and using this. Freedesktop standard supporting systems are probably used by 90% of all Debian desktop users. I doubt that is true. Now you say: No let's use the debian menu system, which only we use and which is not the default of any major WM. This means losing i18n, dynamic construction of menus and icon theming in 90 % of the desktop, because Debian menu items do not support these features. Straw man. We can fairly easily add that stuff. How is this logical? How does the freedesktop standard not gain us features? Because it's not necessary in order to get those features, and they can be added more easily in another way. It's pass a few more text fields through to the menu methods, and use them to generate .desktop files versus rewrite everything. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: Andrew Suffield wrote: On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? And that this information would be lost? Why not run it the other way around, convert the existing debian menu entries to .desktop files and work from there? I think that this way would help debian on the desktops. Because you gain *nothing* and introduce a pointless transition. The question to solve is: In which format shall application packages store their menu information. It doesn't matter, software can make anything look like anything else... the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Users and developers propose following the freedesktop standard and using this. Users and developers are also resisting the proposal. Freedesktop standard supporting systems are probably used by 90% of all Debian desktop users. Unsubstantial, and probably bullshit. Now you say: No let's use the debian menu system, which only we use and which is not the default of any major WM. This means losing i18n, dynamic construction of menus and icon theming in 90 % of the desktop, because Debian menu items do not support these features. How is this logical? How does the freedesktop standard not gain us features? Because nobody but KDE and Gnome use those features and they already support .desktop files. None of which is the problem of the menu package. It just has to read the fields and pass them to the methods, which then write out suitable data files for the frontend. In the case of kde/gnome, that would be a .desktop file; for everything else, yes, the data is thrown away. Nothing else supports those features, and this is again not our problem. freedesktop entry features debian menu file features Therefore you can do a lossless transition from .desktop to menu, but not the other way around. It makes sense to use the .desktop standard. True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. Then those desktops who support it (KDE+Gnome+??) can use the desktop files directly. For other (older or simpler) desktops the debian menu system has to be adapted to use the .desktop files (addditionaly or instead of the menu files). older - stability simpler - faster, less resources hungry I don't understand how anyone can not support this change. Because: Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. also There is currently no way to provide system-wide alternates to the distributed .desktop files. Only having per-user customisation available really, really, sucks, imo. and I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? - Bruce
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, 9 Dec 2003, Tom wrote: On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: freedesktop entry features debian menu file features Therefore you can do a lossless transition from .desktop to menu, but not the other way around. It makes sense to use the .desktop standard. I know what you mean, but don't you mean lossless transition from menu to .desktop ? .desktop is the one that has more features, so a transition from .desktop to menu would lose. It's trivial but I might not understand the issues if its the opposite. It is a metter of perspective. A transition from .desktop to menu only loses if the subsystems using the menu entries are capable of using the lost data. HTH - Bruce
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: Scripsit Andrew Suffield [EMAIL PROTECTED] On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? [...] Because you gain *nothing* Are you claiming that everyone who says that .desktop has technical advantages is a liar? These features actually do not exist in the desktop format? (It may be so; I have no firsthand information, but it does sound far out). No. I'm claiming that everyone who says that only by using .desktop exclusively can we do these things is a liar. Alternate approaches (that involve significantly less work) have been sketched out several times now. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 09:49:54AM -0600, Billy Biggs wrote: Andrew Suffield ([EMAIL PROTECTED]): It's pass a few more text fields through to the menu methods, and use them to generate .desktop files versus rewrite everything. You sure it's rewrite everything? A script to parse all .desktop files in /usr/share/applications and output the same as 'update-menus Straw man, again. The proposal was to rewrite all menu entries as .desktop files - yeah, I'm sure that means rewriting them all. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield ([EMAIL PROTECTED]): On Tue, Dec 09, 2003 at 09:49:54AM -0600, Billy Biggs wrote: Andrew Suffield ([EMAIL PROTECTED]): It's pass a few more text fields through to the menu methods, and use them to generate .desktop files versus rewrite everything. You sure it's rewrite everything? A script to parse all .desktop files in /usr/share/applications and output the same as 'update-menus Straw man, again. The proposal was to rewrite all menu entries as .desktop files - yeah, I'm sure that means rewriting them all. Agreed on that, but it's not rewriting all of the menu package, which is what I felt your post implied. Rewriting all menu files is fairly trivial and does not have to be done all at once. -Billy
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] Straw man, again. The proposal was to rewrite all menu entries as .desktop files - Yes. That is a straw man. -- Henning MakholmNej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: Are you claiming that everyone who says that .desktop has technical advantages is a liar? No. I'm claiming that everyone who says that only by using .desktop exclusively can we do these things is a liar. Then there are no liars on this list. Let's rejoice! -- Henning Makholm Uh ... a picture of me with my hair pinned up in a towel and standing in front of a grid without a trace of makeup? *Are you out of your rock-happy mind?*
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: In which format shall application packages store their menu information. It doesn't matter, If you don't think the problem being discussed matters, why are you participating in the discussion? the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. Users and developers propose following the freedesktop standard and using this. Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. How is this logical? How does the freedesktop standard not gain us features? Because nobody but KDE and Gnome use those features and they already support .desktop files. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. freedesktop entry features debian menu file features True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? -- Henning MakholmI have seen men with a *fraction* of your trauma pray to their deity for death's release. And when death doesn't arrive immediately, they reject their deity and begin to beg to another.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 05:18:21PM -0600, Billy Biggs wrote: | Agreed on that, but it's not rewriting all of the menu package, which | is what I felt your post implied. Rewriting all menu files is fairly | trivial and does not have to be done all at once. It should also be fairly easy to get it mostly, if not entirely, automated. q.v. what KDE and Gnome already do in their menu methods. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 09:49:25PM +, Andrew Suffield wrote: | Alternate approaches (that involve significantly less work) That's the bit that I (and presumably others) am not convinced about. You keep making this assertion, but with little to back it up. Have you, e.g., looked at the Categories definitions for .desktop files? I don't believe that mapping them onto the section field of our menu system (and vice versa) without losing any information would be trivial. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andreas Metzler wrote: Billy Biggs [EMAIL PROTECTED] wrote: Steve Greenland ([EMAIL PROTECTED]): On 04-Dec-03, 14:44 (CST), Nathanael Nerode [EMAIL PROTECTED] wrote: There's now a standard used by KDE and GNOME which has more features than the Debian menu system. And missing one key one: working with menu sysems other than KDE and GNOME. So far there has been a lot of support for the .desktop standard effort. Which systems do you refer to that are not supporting, adopting, or intending to adopt the .desktop standard? Have you any evidence that (or any idea whether) fvwm, icewm, wmaker, lwm, ...[1] plan to support .desktop? It is trivial to support desktop in icewm. Check out icewm.py, one of my few programming exercises. -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield wrote: On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote: Except that AFAIK .desktops are still semantically richer than the existing Debian system, and have more momentum behind them outside of Debian. Upstream packages are much more likely to ship to .desktop files than they are Debian menu entries. Admittedly I'm not convinced that they're ready enough in other ways to replace what we have now. Thing is, none of this matters. If upstream support .desktop files, then we just run them through the script that converts them to Debian menu entries while installing. dh_installmenu would be a good place to do this. You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? And that this information would be lost? Why not run it the other way around, convert the existing debian menu entries to .desktop files and work from there? I think that this way would help debian on the desktops. The extra features should be pretty simple to implement - just more text fields. Hardly. The desktop system in KDE-3.2+ and Gnome-2.4+ is not as static and uncustomizable the Debian menu system at the moment. That way we support the upstream menu entries in everything, not just kde and gnome. -- Moritz Moeller-Herrmann [EMAIL PROTECTED] wiss. Mitarbeiter, IMGB La loi, dans un grand souci d'égalité, interdit aux riches comme aux pauvres de coucher sous les ponts, de mendier dans les rues et de voler du pain. (ANATOLE FRANCE)
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote: Except that AFAIK .desktops are still semantically richer than the existing Debian system, and have more momentum behind them outside of Debian. Upstream packages are much more likely to ship to .desktop files than they are Debian menu entries. Admittedly I'm not convinced that they're ready enough in other ways to replace what we have now. Thing is, none of this matters. If upstream support .desktop files, then we just run them through the script that converts them to Debian menu entries while installing. dh_installmenu would be a good place to do this. You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? And that this information would be lost? Why not run it the other way around, convert the existing debian menu entries to .desktop files and work from there? I think that this way would help debian on the desktops. Because you gain *nothing* and introduce a pointless transition. The extra features should be pretty simple to implement - just more text fields. Hardly. The desktop system in KDE-3.2+ and Gnome-2.4+ is not as static and uncustomizable the Debian menu system at the moment. None of which is the problem of the menu package. It just has to read the fields and pass them to the methods, which then write out suitable data files for the frontend. In the case of kde/gnome, that would be a .desktop file; for everything else, yes, the data is thrown away. Nothing else supports those features, and this is again not our problem. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Marc Wilson wrote: Just as a data point, you do realize that freedesktop.org is a wholly owned and operated subsidiary of RedHat, right? Now this just isn't true. Oh, you don't think so? Take a look at who their god-king is. Take a look at where their mailing lists are hosted. Karsten has detailed in another thread his interactions with that group. Next you'll be saying that GNU binutils and GDB, and perhaps GCC, are wholly owned and operated subsidiaries of Red Hat. Look at who runs them... look at where their mailing lists are hosted The fact is that Red Hat is very generous about hosting free software projects, and does not own or operate most of the projects it hosts. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Marc Wilson [EMAIL PROTECTED] said: On Fri, Dec 05, 2003 at 12:57:53PM +0100, Mathieu Roy wrote: Some or all of: twm, pdmenu, blackbox, afterstep, fluxbox, gtk-menu, wmaker, fvwm2, enlightenment, etc, consult /etc/menu-methods for more. There are dozens of programs that use the debian menus that would have no reason to use the .desktop stuff. Can you name the ones that are still developed in that list? I couldn't pass this up: twm - admittedly, bug-fixes only pdmenu - this is a window manager? blackbox- alive and under current development afterstep - alive and under current development fluxbox - alive and under current development gtk-menu- this is a window manager? wmaker - alive and under current development fvwm2 - alive and under current development e - well, there are CVS commits, call it what you will I only see *one* window manager in that list that isn't alive (twm). Enlightenment is, of course, debatable, and always has been. ^_^ Not that whether or not a package has a release every ten minutes or every ten months has jack to do with whether or not it's useful software. There are any number of other window managers that couldn't care less about .desktop files, yet (a) provide menus, (b) are packaged in Debian. Sure. However, I use WindowMaker since several years now, and apart from bug fixes, I did not notice real changes over years (the changelog does not speak otherwise, it's almost only about bugs and i18n updates). About blackbox, http://blackboxwm.sourceforge.net/, there no news since September the 2nd... 2002. It's maybe a mistake to say that these projects are no longer active at all, however their activity by comparison to GNOME and KDE is pretty small. I'm not criticizing inactivity, there are understandable reasons behind it. For instance, on WindowMaker website, it's told that the development is not going on because the main authors are busy in real life: in GNOME and KDE case, I think that numerous author works for these projects in their real professionnal life (am I wrong?), so it is easier to keep moving. Why do you say that this programs would have no reason to use the .desktop stuff? What reasons would they have to use the Debian Menu instead? They don't. That simple data point seems to be missing from the entire discussion. They use their own internal menu formats. Thus, we have the menu package, which takes *Debian's* window-manager-independent menu entries, and creates for each of these window managers something that they can digest in their own format. Saying Debian should provide .desktop files is all well and good. Perhaps it should even be encouraged. But there is still a great need for what the menu package does. Ok, it would be indeed interesting that this Debian tool that make the conversion get compatible with .desktop files. This tool would be interesting for any distributions that ships these wm also. For instance, if I correctly understood the story, RedHat stopped shipping WindowMaker because they do not want to support a window manager that do not follow the agreements between KDE and GNOME people, freedesktop.org in fact. Regards, -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 5 Dec 2003 11:09:56 -0600, Chad Walstrom [EMAIL PROTECTED] said: On Fri, Dec 05, 2003 at 04:08:41AM -0600, Manoj Srivastava wrote: ... It only stands to reason that if both the KDE and Gnome desktop camps wish to formalize on the format that we should adopt it as well, if only as an extension of our menu system. We would have to generate .desktop files anyway, when Gnome and KDE move form their own native menu formats. You talk as if the whole universe of window managers is merely gnome and kde. I understand how you might get that, but you have to admit that they are the most visible of the desktop environments. I didn't mention window managers specifically because I don't see the need to make the distinction in this case. The .desktop files has the same goal and focus as a .menu file -- providing a convenient interface to finding and launching applications, so let's keep that the focus of the discussion. Part of the focus of this discussion is about the obstacles we have facing a transition to .desktop entries. And this is one of them -- until there exists a mechanism to convert .desktop entries into things that the back-end WM's can grok, we are stymied (since we have a system that works, however imperfectly, and dropping support for these window mangers would be a regression). The other part is, of course, teaching developers how to write the .desktop menu item, and I for one, have never seen one. manoj -- I hope the ``Eurythmics'' practice birth control ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 5 Dec 2003 16:48:28 -0500, Joey Hess [EMAIL PROTECTED] said: [I whole heartedly agree with Joey here. I am just adding a few remarks] No, you're going about this backwards. Get the code written. Get the policy for Debian menu layout using .desktop files written. Make sure that there's a plan for how the transition will work. Only then does it make sense to begin asking maintainers to switch to .desktop files. You do not need the policy to be a formal policy either -- get a few like minded people to participate, and the policy can evolve with the code as you work out the bugs. A working set of packages using the code and policies, even if in a test environment, goes a long way convince people of the feasibility. Because until you have code and a policy, you cannot test the menu items you are adding, and you do not know they will fit within the policies we will eventually devise for layout, wording, icons, whatever, for .desktop menu entries. And because in the meantime it leads to bloat, and to poor UI. By going about this backwards, you only double the amount of work that maintainers who add .desktop files will eventually have to do, and you do nothing to advance your goal of widespread use of .desktop files in Debian. If you would write some code, come up with a clear and workable transition plan, and go through regular channels to get it into policy, you would find that most developers would move to the new system with only a little nudging. As it is, you're setting yourself up for a fight every step of the way, and it's painful to watch. In the past, policies have been developed and matured outside the staid old debian technical policy, and thus unfettered by the procedural constraints of the policy process until they had been field tested, and had critical mass to get formally approved rapidly. manoj -- There are more things in heaven and earth than any place else. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 10:05:57AM +0100, Mathieu Roy wrote: | Sure. However, I use WindowMaker since several years now, and apart | from bug fixes, I did not notice real changes over years (the | changelog does not speak otherwise, it's almost only about bugs and | i18n updates). | | About blackbox, http://blackboxwm.sourceforge.net/, there no news | since September the 2nd... 2002. | | It's maybe a mistake to say that these projects are no longer active | at all, however their activity by comparison to GNOME and KDE is | pretty small. What's your point? The window managers don't /need/ to be changed - or at least they shouldn't. They don't natively support Debian's menu system, they don't natively support .desktop files, and are unlikely to ever do either. The current Debian menu system, despite its faults, supports writing menus for weird formats that an arbitrary window manager (or other menuing system) might be able to read. If .desktops are ever to achieve prominence in Debian, we need to be able to do the same with those. (Personally, I feel that extending the current menu system such that it is both backwards-compatible with what we have not and supports everything in the freedesktop.org standard is not as trivial as Andrew has suggested it is in another thread - but if it was accomplished, we wouldn't have to worry about window managers not supporting .desktop files as their configuration would be generated just as they are now using existing menu-methods.) | For instance, if I correctly understood the story, RedHat stopped | shipping WindowMaker because they do not want to support a window | manager that do not follow the agreements between KDE and GNOME | people, freedesktop.org in fact. There is no reason for Debian to do something merely because Red Hat does. Trying to make Debian compliant with freedesktop's standards by dropping everything that doesn't support them is a sub-optimal approach, and is unlikely to be taken seriously by many people. Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Cameron Patrick [EMAIL PROTECTED] said: On Sat, Dec 06, 2003 at 10:05:57AM +0100, Mathieu Roy wrote: | Sure. However, I use WindowMaker since several years now, and apart | from bug fixes, I did not notice real changes over years (the | changelog does not speak otherwise, it's almost only about bugs and | i18n updates). | | About blackbox, http://blackboxwm.sourceforge.net/, there no news | since September the 2nd... 2002. | | It's maybe a mistake to say that these projects are no longer active | at all, however their activity by comparison to GNOME and KDE is | pretty small. What's your point? The window managers don't /need/ to be changed - or at least they shouldn't. They don't natively support Debian's menu system, they don't natively support .desktop files, and are unlikely to ever do either. The current Debian menu system, despite its faults, supports writing menus for weird formats that an arbitrary window manager (or other menuing system) might be able to read. I do not understand how can you, in one hand, say there no need for a standard like .desktop for these window managers (well, this term is questionnable - wmaker is, for instance, more than a windowmanager), and, in another hand, talk about weird formats of different window manager. The point of .desktop is to avoid having weird formats to handle, but only one. If these environment needs the data, or part of the data, that can be contained in .desktop (currently provided by the debian menu system), why would it be stupid for them to be able to deal directly with .desktop? If .desktops are ever to achieve prominence in Debian, we need to be able to do the same with those. Sure, as long as some environment will not support .desktop while needing the data contained in .desktop, Debian will have to use converters. | For instance, if I correctly understood the story, RedHat stopped | shipping WindowMaker because they do not want to support a window | manager that do not follow the agreements between KDE and GNOME | people, freedesktop.org in fact. There is no reason for Debian to do something merely because Red Hat does. Why do you assume that I want Debian to follow RedHat choice? Trying to make Debian compliant with freedesktop's standards by dropping everything that doesn't support them is a sub-optimal approach, and is unlikely to be taken seriously by many people. Nobody proposed that. I do not see the point in arguing about a non-existant proposal. -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 11:25:31AM +0100, Mathieu Roy wrote:
| What's your point? The window managers don't /need/ to be changed - or
| at least they shouldn't. They don't natively support Debian's menu
| system, they don't natively support .desktop files, and are unlikely to
| ever do either. The current Debian menu system, despite its faults,
| supports writing menus for weird formats that an arbitrary window
| manager (or other menuing system) might be able to read.
|
| I do not understand how can you, in one hand, say there no need for a
| standard like .desktop for these window managers (well, this term is
| questionnable - wmaker is, for instance, more than a windowmanager),
| and, in another hand, talk about weird formats of different window
| manager.
The situation /now/ is that /most/ window managers use their own unique
format to handle their menus. Even the versions of KDE and Gnome
currently in Debian, while both using .desktop files, store them in a
different place and place them into menu hierarchies differently.
A standard like .desktop or the Debian menu system we have now /is/ a
good thing; we also need a way to make those menu hierarchies available
to applications which cannot and will not read them directly (hence the
weird formats that I mentioned). Currently, freedesktop provides the
former but not the latter, so in order for freedesktop's scheme to be
considered as a replacement for what we use now, there must also be a
way to convert them into the format used by some arbitrary menu system.
In practice, a way to convert existing menu entries into the new system,
and ideally also a way to make use of existing menu-methods, would also
be required.
(I'm sorry, I was imprecise earlier: when I said window managers I was
actually referring to any piece of software which displays a menu of
applications available on the system.)
| The point of .desktop is to avoid having weird formats to handle,
| but only one.
The point is that applications which provide menu entries don't need to
care about about the format that a particular window manager may want
that menu item in. Currently the Debian menu system provides one such
standard format; another candidate is .desktop files.
| If these environment needs the data, or part of the data, that can be
| contained in .desktop (currently provided by the debian menu system),
| why would it be stupid for them to be able to deal directly with
| .desktop?
Of course not. But a lot - in fact, the overwhelming majority - of
these environments predate .desktop files, and are unlikely to change.
They don't integrate directly with any menu system but their own. For
new window managers (or or menu systems), I agree, it makes sense to use
.desktop files for the appropriate menu, as they are more widely
supported outside of Debian.
| If .desktops are ever to achieve prominence in Debian, we need to be
| able to do the same with those.
|
| Sure, as long as some environment will not support .desktop while
| needing the data contained in .desktop, Debian will have to use
| converters.
I claim once again that this will always - at least for the forseeable
future - be the case. Converters for the .desktop format don't yet
exist; converters for the current system are in place and working right
now for /every/ menu system in Debian ... with the exception of KDE and
GNOME, where the Debian menu appears to be treated as a second-class
citizen compared to the {GNOME,KDE}-specific menu. *sigh*
| There is no reason for Debian to do something merely because Red Hat
| does.
|
| Why do you assume that I want Debian to follow RedHat choice?
[...]
| Nobody proposed that. I do not see the point in arguing about a
| non-existant proposal.
In that case, why did you mention what Red Hat were doing?
Cheers,
Cameron.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Cameron Patrick [EMAIL PROTECTED] said: [...] A standard like .desktop or the Debian menu system we have now /is/ a good thing; we also need a way to make those menu hierarchies available to applications which cannot and will not read them directly (hence the weird formats that I mentioned). Currently, freedesktop provides the former but not the latter, so in order for freedesktop's scheme to be considered as a replacement for what we use now, there must also be a way to convert them into the format used by some arbitrary menu system. In practice, a way to convert existing menu entries into the new system, and ideally also a way to make use of existing menu-methods, would also be required. Ok. [...] Of course not. But a lot - in fact, the overwhelming majority - of these environments predate .desktop files, and are unlikely to change. They don't integrate directly with any menu system but their own. For new window managers (or or menu systems), I agree, it makes sense to use .desktop files for the appropriate menu, as they are more widely supported outside of Debian. Ok. [...] | There is no reason for Debian to do something merely because Red Hat | does. | | Why do you assume that I want Debian to follow RedHat choice? [...] | Nobody proposed that. I do not see the point in arguing about a | non-existant proposal. In that case, why did you mention what Red Hat were doing? Since the paragraph where I mentioned RedHat is no longer quoted, it is less obvious why I mentioned it. I mentioned RedHat choice has an example of major GNU/Linux contributor that apparently decided that current development activity on the project WindowMaker is too low to continue to support commercially WindowMaker. I have to admit that all the information I can found about that is very laconic, for instance, in http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/release-notes/x86/ is says that wmaker has been removed due to Developer resource constraints. I remember about a message from a guy from RedHat saying more or less that he see no point in supporting an environment/wm that do not follow the new standards decided at freedesktop.org (is open to anybody if I understood right), that makes hard for RedHat to avoid some specific troubles, to provide support easily. But I'm not able to remember where I seen that message, so maybe it was a mistake from me. This example was not meant to be a plan for Debian but an example of persons thinking that it could make sense for wmaker to consider following freedesktop.org standards in some cases. The point was only: apparently it does not look so dumb to everybody to consider using .desktop even for some of the environment/wm listed by someone previously in this discussion. (A bad example, I have to admit, considering the size of my explanation of its usage) -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 06:02:16PM +0100, Mathieu Roy wrote: I remember about a message from a guy from RedHat saying more or less that he see no point in supporting an environment/wm that do not follow the new standards decided at freedesktop.org... Just as a data point, you do realize that freedesktop.org is a wholly owned and operated subsidiary of RedHat, right? Oh, you don't think so? Take a look at who their god-king is. Take a look at where their mailing lists are hosted. Karsten has detailed in another thread his interactions with that group. Then think about whether RedHat has a vested interest in *not* supporting anything that doesn't view the world the same way their annointed God of the Desktop does. -- Marc Wilson | stu Stupid nick highlighting stu Whenever someone [EMAIL PROTECTED] | starts with stupid it highlights the nick. Hmm. | -- #Debian
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sun, 2003-12-07 at 08:41, Marc Wilson wrote: On Sat, Dec 06, 2003 at 06:02:16PM +0100, Mathieu Roy wrote: I remember about a message from a guy from RedHat saying more or less that he see no point in supporting an environment/wm that do not follow the new standards decided at freedesktop.org... Just as a data point, you do realize that freedesktop.org is a wholly owned and operated subsidiary of RedHat, right? Oh, you don't think so? Take a look at who their god-king is. Take a look at where their mailing lists are hosted. Karsten has detailed in another thread his interactions with that group. Then think about whether RedHat has a vested interest in *not* supporting anything that doesn't view the world the same way their annointed God of the Desktop does. Ahh ... thanks for pointing this out. I knew there was a conspiracy to pre-empt and subvert all competing desktop standardization efforts. By no less than those evil Microsoft wannabes themselves, Red Hat! We should take it even more personally - no point dealing on superfluous technical level. Cynicism aside, can anyone point to Carsten's thread for some other individual's POV? ta zen -- Debian Enterprise GNU/Linux: http://debian-enterprise.org/ * Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc * Please respect the confidentiality of this email as sensibly warranted.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, 2003-12-06 at 16:41, Marc Wilson wrote: On Sat, Dec 06, 2003 at 06:02:16PM +0100, Mathieu Roy wrote: I remember about a message from a guy from RedHat saying more or less that he see no point in supporting an environment/wm that do not follow the new standards decided at freedesktop.org... Just as a data point, you do realize that freedesktop.org is a wholly owned and operated subsidiary of RedHat, right? That's simply not true. Plenty of people contribute to freedesktop.org outside of Red Hat. I know a number of Debian developers who do, for example. Oh, you don't think so? Take a look at who their god-king is. Take a look at where their mailing lists are hosted. You might notice that Red Hat hosts a lot of *other* mailing lists too: http://www.redhat.com/mailman/listinfo And I suppose hosting say the BLinux list is all part of another conspiracy? Then think about whether RedHat has a vested interest in *not* supporting anything that doesn't view the world the same way their annointed God of the Desktop does. It's hard to try to take this seriously, but: what is this supposed vested interest? signature.asc Description: This is a digitally signed message part
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Sat, Dec 06, 2003 at 01:40:58AM -0600, Manoj Srivastava wrote: -- until there exists a mechanism to convert .desktop entries into things that the back-end WM's can grok, we are stymied Agreed. (since we have a system that works, however imperfectly, and dropping support for these window mangers would be a regression). Never suggested it. Personally, I like menu files. They're simple, direct, and provide a great service to Debian. The other part is, of course, teaching developers how to write the .desktop menu item, and I for one, have never seen one. That hasn't stopped us before. ;-p I agree though, it's a learning process. I haven't looked at the menu code, so I don't know how difficult it'ld be to throw in a .desktop file parser/converter. Don't get me wrong, I didn't ever suggest abandoning Debian menu. I only suggested that participating in something that may turn out to be a standard amongst desktop environments will only benefit us. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpnDHrLTlFif.pgp Description: PGP signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 02:36:37AM +, Andrew Suffield wrote: | Right, that's what I just described (later on). The thread had | previously been about people wanting to throw away the Debian menu | system and replace it with the .desktop one, or worse, have both | coexist. If we can convert menu entries between the two formats and do so in a sane manner, having the two coexist shouldn't be a problem, and could potentially be the first step towards standardising on freedesktop's format. I agree, though, that having the two coexist with completely different menu items on each is a bad position to be in - and sadly, that's pretty much what we've got now :( I just had a look at the menus of both KDE and Gnome, and it seems that even though the .desktop file format is supposedly common to both, they have different menus with, for the most part, non-intersecting sets of programs on each. Aaargh! This is bad, and I think it needs to be fixed if we are to attempt to do too much more with .desktop files. | Yeah, inverted the sense, you get the idea. We need both tools, at | which point there's no longer a reason not to just continue using the | existing Debian menu system. Except that AFAIK .desktops are still semantically richer than the existing Debian system, and have more momentum behind them outside of Debian. Upstream packages are much more likely to ship to .desktop files than they are Debian menu entries. Admittedly I'm not convinced that they're ready enough in other ways to replace what we have now. | In fact, it looks like it's been implemented twice, once for KDE and | once for GNOME. (Is there any reason why the .desktop files aren't being | shared between the two DE's? It also appears to me that KDE is doing a | marginally better job of integrating the Debian menu into the KDE menu.) | | Yup, that. It needs de-stupiding, which basically means rewriting, | given the triviality of this particular part. Agreed. In my opinion, the current Debian menu hierarchy is a nightmare from a usability perspective. There is a freedesktop.org menu spec[1] that builds upon .desktop entries and sounds to me as though is should help some of these problems, by having .desktop files assigned to multiple categories and attempting to generate a menu hierarchy from those. It also supports merging menus from multiple sources, which might make it easier to incorporate Debian menu entries into it. However, I don't believe it's actually been implemented by anyone yet, and I'm not making any claims about how useful it might be practice. Cheers, Cameron. [1] http://freedesktop.org/Standards/menu-spec/menu-spec-0.8.html - mentioned on the debian-usability list months ago.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Billy Biggs [EMAIL PROTECTED] wrote: Steve Greenland ([EMAIL PROTECTED]): On 04-Dec-03, 14:44 (CST), Nathanael Nerode [EMAIL PROTECTED] wrote: There's now a standard used by KDE and GNOME which has more features than the Debian menu system. And missing one key one: working with menu sysems other than KDE and GNOME. So far there has been a lot of support for the .desktop standard effort. Which systems do you refer to that are not supporting, adopting, or intending to adopt the .desktop standard? Have you any evidence that (or any idea whether) fvwm, icewm, wmaker, lwm, ...[1] plan to support .desktop? cu andreas [1] Insert any of 'grep-available -FProvides -s Package window-manager' with menu-support here.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 4 Dec 2003 13:18:46 -0600, Chad Walstrom [EMAIL PROTECTED] said: On Thu, Dec 04, 2003 at 04:49:45PM -0200, Felipe Almeida Lessa wrote: I think only one thing is blocking the whole idea of moving from Debian Menu style to freedesktop.org style: the work that need to be done. In other words, people don't wanna use the .desktop format because the have already write a debian/menu. Then extend the functionality of the Debian menu system to use .desktop format as both an OPTIONAL target and an optional SOURCE. Doing so might ease the burden and barrier to utilizing .desktop files. It only stands to reason that if both the KDE and Gnome desktop camps wish to formalize on the format that we should adopt it as well, if only as an extension of our menu system. We would have to generate .desktop files anyway, when Gnome and KDE move form their own native menu formats. You talk as if the whole universe of window managers is merely gnome and kde. manoj -- We cannot command nature except by obeying her. Sir Francis Bacon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, 4 Dec 2003 15:44:56 -0500, Nathanael Nerode [EMAIL PROTECTED] said: Frankly, I'm not clear why there's opposition to adopting the freedesktop draft specifications in Debian. I use neither gnome nor KDE. My window manager of choice shows me the Debian entries in the menu. The code that would enable similar functionality from .desktop entries is not yet written. manoj -- Out of the same substances one stomach will extract nourishment, another poison; and so the same disappointments in life will chasten and refine one man's spirit, and embitter another's. -- William Matthews Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Zenaan Harkness [EMAIL PROTECTED] said: On Fri, 2003-12-05 at 05:49, Felipe Almeida Lessa wrote: On Thursday 04 December 2003 13:19, Andrew Suffield wrote: The other question is how hard could it be to adapt menu to desktop files ?. I think only one thing is blocking the whole idea of moving from Debian Menu style to freedesktop.org style: the work that need to be done. In other words, people don't wanna use the .desktop format because the have already write a debian/menu. This is my impression from the threads too. If it is just a matter of time, the transition can be done step by step: the first step is just to say that this transition should be done. It doesn't need to be done in two days, does it? If new packages start directly with .desktop and others packages move to .desktop in the next year, it does not seems to be an awful load of extra work. -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Steve Greenland [EMAIL PROTECTED] said: As for me, I'm happy to provide either my current menu files, which are supported by all of the DE/WM systems in Debian, *or* .desktop files, *when* they are supported by all (or at least most) the DE/WM systems in Debian. If everybody waits the .desktop to be supported by anybody else to start supporting it, it will never be supported in any way. -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield [EMAIL PROTECTED] said: [...] I don't think that this is the case. As I understand it, .desktop files have the advantage that they are already shipped by a number of upstream packages, support i18n better than Debian menus, are supported natively by KDE and Gnome, include facilities for providing stuff like generic names and are supported by the freedesktop.org folk. That wasn't his argument. However, it's similar, and the response is the same: why not simply add these features to the Debian menu system? Nothing you've described is particularly difficult, or anything that we haven't done before in different contexts. Do you truly think that it is better that every different people looking after the exact same features writes each of them their own software? I'm more inclined to think that refusing to collaborate with other people should be motivated by strong divergences on the goal to reach and the method to follow ; not just because it is *possible* to do everything on our own. Are they strong divergences on the goal to rach and the method to follow between Debian and freedesktop.org? -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Joey Hess [EMAIL PROTECTED] said: Billy Biggs wrote: So far there has been a lot of support for the .desktop standard effort. Which systems do you refer to that are not supporting, adopting, or intending to adopt the .desktop standard? Some or all of: twm, pdmenu, blackbox, afterstep, fluxbox, gtk-menu, wmaker, fvwm2, enlightenment, etc, consult /etc/menu-methods for more. There are dozens of programs that use the debian menus that would have no reason to use the .desktop stuff. Can you name the ones that are still developed in that list? Only one half, I'm afraid. It is not a big surprise that wmaker does not support a standard created more or less when the latest, only bugfixes, release was published. Why do you say that this programs would have no reason to use the .desktop stuff? What reasons would they have to use the Debian Menu instead? -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Andrew Suffield [EMAIL PROTECTED] said: On Thu, Dec 04, 2003 at 12:34:22AM +0100, Raphael Goulais wrote: On Wednesday 03 December 2003 21:31, Zenaan Harkness wrote: I agree. I would like to see .desktop standard adopted. There have been a few threads I have seen so far, and there seems to be some level of resistance to the idea. The silly question is : What does our actual menu system provide that shouldn't be achieved by using .desktop file ? As those are going to be a standard, we should deal with them. You could swap our menu system and .desktop files here and your argument would still be about as valid. Only if you disregard the last sentence of Raphael: our menu system is definitely not going to be a standard (outside debian), is it? (In fact, only this last sentence is an argument, the other one is a question.) If there are no technical differences between two solutions but one is standard in many places (or going to be standard) and the other is just known at home, which one is the best? -- Mathieu Roy +-+ | General Homepage: http://yeupou.coleumes.org/ | | Computing Homepage: http://alberich.coleumes.org/ | | Not a native english speaker: | | http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english | +-+
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, 05 Dec 2003 04:08:41 -0600, Manoj Srivastava [EMAIL PROTECTED] escreveu: On Thu, 4 Dec 2003 13:18:46 -0600, Chad Walstrom [EMAIL PROTECTED] said: On Thu, Dec 04, 2003 at 04:49:45PM -0200, Felipe Almeida Lessa wrote: I think only one thing is blocking the whole idea of moving from Debian Menu style to freedesktop.org style: the work that need to be done. In other words, people don't wanna use the .desktop format because the have already write a debian/menu. Then extend the functionality of the Debian menu system to use .desktop format as both an OPTIONAL target and an optional SOURCE. Doing so might ease the burden and barrier to utilizing .desktop files. It only stands to reason that if both the KDE and Gnome desktop camps wish to formalize on the format that we should adopt it as well, if only as an extension of our menu system. We would have to generate .desktop files anyway, when Gnome and KDE move form their own native menu formats. You talk as if the whole universe of window managers is merely gnome and kde. Now I'm using GNOME, but some time ago I have used XFce, Window Maker and others. IMHO, we could have a script that converted new .desktop to old-style Debian Menu while the WM don't understand .desktop. Or even better, we could make it understand :-). OTOH, it could require some work. Actually, for me it would be very hard to make any of these scripts, as I don't have the knowledge that would be necessary, so I'm just saying my opinions. []'s, Felipe Almeida Lessa. pgpBRiDk6JzJB.pgp Description: PGP signature
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 01:17:08PM +, Andrew Suffield wrote: | Thing is, none of this matters. If upstream support .desktop files, | then we just run them through the script that converts them to Debian | menu entries while installing. dh_installmenu would be a good place to | do this. | | The extra features should be pretty simple to implement - just more | text fields. That way we support the upstream menu entries in | everything, not just kde and gnome. Yeah, whatever. Just so long as the current mess is resolved one way or another, I don't have that strong a preference in favour of one system or the other. Given that extra features should be added to Debian's menus anyway, and that no matter what happens there's going to be a need to convert between .desktops and Debian menu entries, I can't see why it should really matter which format is preferred. Cameron.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 03:02:42PM +0800, Cameron Patrick wrote: | Yeah, inverted the sense, you get the idea. We need both tools, at | which point there's no longer a reason not to just continue using the | existing Debian menu system. Except that AFAIK .desktops are still semantically richer than the existing Debian system, and have more momentum behind them outside of Debian. Upstream packages are much more likely to ship to .desktop files than they are Debian menu entries. Admittedly I'm not convinced that they're ready enough in other ways to replace what we have now. Thing is, none of this matters. If upstream support .desktop files, then we just run them through the script that converts them to Debian menu entries while installing. dh_installmenu would be a good place to do this. The extra features should be pretty simple to implement - just more text fields. That way we support the upstream menu entries in everything, not just kde and gnome. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Em Fri, 5 Dec 2003 21:55:21 +0800, Cameron Patrick escreveu:
On Fri, Dec 05, 2003 at 01:17:08PM +, Andrew Suffield wrote:
| Thing is, none of this matters. If upstream support .desktop files,
| then we just run them through the script that converts them to Debian
| menu entries while installing. dh_installmenu would be a good place to
| do this.
|
| The extra features should be pretty simple to implement - just more
| text fields. That way we support the upstream menu entries in
| everything, not just kde and gnome.
Yeah, whatever. Just so long as the current mess is resolved one way or
another, I don't have that strong a preference in favour of one system
or the other. Given that extra features should be added to Debian's
menus anyway, and that no matter what happens there's going to be a need
to convert between .desktops and Debian menu entries, I can't see why it
should really matter which format is preferred.
I agree, as far as GNOME and KDE stop using two kinds of menus at the same time.
What about adding {icon[1],i18n,etc} support to Debian Menu, as others said on
this thread? If we can automate .desktop = Debian process, so there's no *big*
reason to use freedesktop.org standard, as the main advantage would become the
fact of being a standard :-).
Also, the program icons in Debian menus is one thing that is annoying me since
I met Debian, as I can't use them in a larger size (aka in my desktop)
beautifully.
Cheers,
Felipe Almeida Lessa.
[1] I'm talking about categories, not programs.
pgpnLXfoz0Cw8.pgp
Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On 05-Dec-03, 05:54 (CST), Mathieu Roy [EMAIL PROTECTED] wrote: Steve Greenland [EMAIL PROTECTED] said: As for me, I'm happy to provide either my current menu files, which are supported by all of the DE/WM systems in Debian, *or* .desktop files, *when* they are supported by all (or at least most) the DE/WM systems in Debian. If everybody waits the .desktop to be supported by anybody else to start supporting it, it will never be supported in any way. Are you being deliberately obtuse? I'm saying that when the other DE/WM systems support .desktop files, either natively or via translataion (which is exactly how the current Debian menu files are supported), *along with the current menu files*, then individual packages can start transitioning to the .desktop format without breaking every desktop environment in Debian except GNOME and KDE. At best, this requires only (only!) a tool in the menu package that reads .desktop and generates Debian menu files when appropriate, which would be run out of the menu installation hook before the menu methods are run to create the WM/DE native menu formats. But I haven't looked at the menu system structure for a while, so someone who actually knows what they're talking about should probably speak up now. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 04:08:41AM -0600, Manoj Srivastava wrote: ... It only stands to reason that if both the KDE and Gnome desktop camps wish to formalize on the format that we should adopt it as well, if only as an extension of our menu system. We would have to generate .desktop files anyway, when Gnome and KDE move form their own native menu formats. You talk as if the whole universe of window managers is merely gnome and kde. I understand how you might get that, but you have to admit that they are the most visible of the desktop environments. I didn't mention window managers specifically because I don't see the need to make the distinction in this case. The .desktop files has the same goal and focus as a .menu file -- providing a convenient interface to finding and launching applications, so let's keep that the focus of the discussion. -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ pgpQm2EmGr3TA.pgp Description: PGP signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Mathieu Roy wrote: If it is just a matter of time, the transition can be done step by step: the first step is just to say that this transition should be done. It doesn't need to be done in two days, does it? If new packages start directly with .desktop and others packages move to .desktop in the next year, it does not seems to be an awful load of extra work. If that happened then we would, for an undefined length of time that would probably span a Debian release, have two divergent sets of menus, with some programs randomly on the Debian menus, and some programs randomly on the free desktop menus. This would be unusable, and a bad regression. You speak of a transition, but I see no transition plan here. I suppose that this thread is useless, and someone will eventually write code, and that person will be the one who decides how it works. -- see shy jo signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Mathieu Roy wrote: So far there has been a lot of support for the .desktop standard effort. Which systems do you refer to that are not supporting, adopting, or intending to adopt the .desktop standard? Some or all of: twm, pdmenu, blackbox, afterstep, fluxbox, gtk-menu, wmaker, fvwm2, enlightenment, etc, consult /etc/menu-methods for more. There are dozens of programs that use the debian menus that would have no reason to use the .desktop stuff. Can you name the ones that are still developed in that list? Only one half, I'm afraid. It is not a big surprise that wmaker does not support a standard created more or less when the latest, only bugfixes, release was published. Every peice of software I listed is part of Debian, and supported by Debian. Why do you say that this programs would have no reason to use the .desktop stuff? What reasons would they have to use the Debian Menu instead? Some of the listed programs have nothing to do with a desktop menu standard, and have zero chance of supporting it upstream. The Debian menu system creates native config files in the format these programs use. -- see shy jo signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Joey Hess [EMAIL PROTECTED] Mathieu Roy wrote: It doesn't need to be done in two days, does it? If new packages start directly with .desktop and others packages move to .desktop in the next year, it does not seems to be an awful load of extra work. If that happened then we would, for an undefined length of time that would probably span a Debian release, have two divergent sets of menus, with some programs randomly on the Debian menus, and some programs randomly on the free desktop menus. This would be unusable, and a bad regression. Evidently, so that's not what is proposed. The proposal is to enhance update-menus such that it knows how to parse .desktop files and feed the information from them transparently to menu methods that expect the Debian native format. Then debian-native menu systems would give the same user experience independently of which packages had transitioned to the .desktop format. Packages that uses the .desktop format natively already have maintainer scripts that know how to translate debianized menu entries into that. They may need some cooperation from update-menus in order to not show two entries for things that have .desktop entries of their own, but that is also minor. You speak of a transition, but I see no transition plan here. What do you expect from a transition plan then? Step 1a: Update menu infrastructure such that packages can transparently supply either .desktop files or Debian menu files. Step 1b: At the same time, update menu infrastructure such that WM packages providing menu methods can opt to receive package data in .desktop format (autotranslated from Debian menu files if necessary). Step 2: Packagers can now chose to supply .desktop files instead of the Debian format, with a versioned dependency on menu. Step 3: After a stable version with the updated infrastructure has been released, the Debian menufile format can be deprecated (should not happen before, because it would make backports harder). Step 4: When all (or most) menu methods have been converted to reading .desktop files, policy can be amended along the lines of *must* provide a .desktop file rather than the old Debian-specific menu format. Stem 5: Compatibility code for the old format in the menu infrastructure will be kept until it gets too much of a burden to maintain it. -- Henning MakholmWhat the hedgehog sang is not evidence.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Hi, Herbert Xu wrote:
If you think that it's so obvious, why don't you start by addressing my
objections in the quoted bug report?
I see only one -- duplicate work, which has been beaten to death already.
But since you insist on my opinion ...
The fact is that it isn't. At time X, which is when a .desktop file has
been written, said file can be added to the package it's written for.
At time Y, which is when there is lossless conversion from .desktop files
to menu files and/or when all menu managers can process .desktop files
directly, the old menu files may be deleted.
Given that there are a number of packages with old menu files which
require conversion, I do not see why, for any given package, the times X
and Y need to be identical.
The duplicate work argument is IMHO not applicable. Nobody's going to
force you to continue actively maintaining the old files, is there?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Beware of limbo dancers! (written at bottom of bathroom stall door with arrow
pointing down)
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Hi, Mathieu Roy wrote:
Are they strong divergences on the goal to reach and the method to
follow between Debian and freedesktop.org?
There don't seem to be.
But, assuming that we assume that .desktop files are The Future (they
have technical advantages over our menu files, and Debian is about doing
the right thing), there seem to be divergent opinions on how to go about
actually migrating to them.
We can
1- supply both in our packages
2- write conversion scripts menu = .desktop
3- patch menu managers to understand them directly and supply that
to Upstream
4- write conversion scripts .desktop = menu_manager_of_choice and supply
that to Upstream
IMHO, -4- and -3- are both good solutions; the choice is Upstream's.
Not doing -1- or -2- until it's no longer necessary because -3- and
-4- obsolete them doesn't work particularly well, and neither does not
doing -1- because -2- obsoletes it.
The reason why it doesn't is rather simple -- a change like this needs
both enough .desktop files, _and_ support from programs, to work.
Otherwise, nobody will switch.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Nothing is rich but the inexhaustible wealth of nature.
She shows us only surfaces, but she is a million fathoms deep.
-- Ralph Waldo Emerson
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Henning Makholm wrote: Evidently, so that's not what is proposed. The proposal is to enhance update-menus such that it knows how to parse .desktop files and feed the information from them transparently to menu methods that expect the Debian native format. Then debian-native menu systems would give the same user experience independently of which packages had transitioned to the .desktop format. The head of this thread is about someone asking several developers to drop .desktop files into their packages right now. Matthias Urlichs [EMAIL PROTECTED] wrote: AKL. Mantas Kriauciunas wrote: Herbert Xu: Please discuss this on debian-devel before filing further bugs. IMHO, there's no need to discuss this to death -- .desktop files make sense, therefore packages should supply them. There's no sane way to ask maintainers to do so except to file bugs, therefore bugs should be filed, and that's all there is to it. There are bugs in the BTS about this, for example #219304. This is being gone about ass-backwards. You speak of a transition, but I see no transition plan here. What do you expect from a transition plan then? Step 1a: Update menu infrastructure such that packages can transparently supply either .desktop files or Debian menu files. Step 1b: At the same time, update menu infrastructure such that WM packages providing menu methods can opt to receive package data in .desktop format (autotranslated from Debian menu files if necessary). Step 2: Packagers can now chose to supply .desktop files instead of the Debian format, with a versioned dependency on menu. Step 3: After a stable version with the updated infrastructure has been released, the Debian menufile format can be deprecated (should not happen before, because it would make backports harder). Step 4: When all (or most) menu methods have been converted to reading .desktop files, policy can be amended along the lines of *must* provide a .desktop file rather than the old Debian-specific menu format. Stem 5: Compatibility code for the old format in the menu infrastructure will be kept until it gets too much of a burden to maintain it. Apparently some people are trying to start at something not unlike your step 2, without changing menu first. -- see shy jo signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Fri, Dec 05, 2003 at 08:05:34PM +, Henning Makholm wrote: You speak of a transition, but I see no transition plan here. What do you expect from a transition plan then? Step 1a: Update menu infrastructure such that packages can transparently supply either .desktop files or Debian menu files. Step 1b: At the same time, update menu infrastructure such that WM packages providing menu methods can opt to receive package data in .desktop format (autotranslated from Debian menu files if necessary). Step 2: Packagers can now chose to supply .desktop files instead of the Debian format, with a versioned dependency on menu. I can see no reason to proceed any further than this. The remaining stuff: Step 3: After a stable version with the updated infrastructure has been released, the Debian menufile format can be deprecated (should not happen before, because it would make backports harder). Step 4: When all (or most) menu methods have been converted to reading .desktop files, policy can be amended along the lines of *must* provide a .desktop file rather than the old Debian-specific menu format. Stem 5: Compatibility code for the old format in the menu infrastructure will be kept until it gets too much of a burden to maintain it. Seems pointless. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Joey Hess [EMAIL PROTECTED] Henning Makholm wrote: The proposal is to enhance update-menus such that it knows how to parse .desktop files and feed the information from them transparently to menu methods that expect the Debian native format. The head of this thread is about someone asking several developers to drop .desktop files into their packages right now. Yes, so people got wiser along the way. Isn't that supposed to be what happens in these discussions? -- Henning MakholmWe can hope that this serious deficiency will be remedied in the final version of BibTeX, 1.0, which is expected to appear when the LaTeX 3.0 development is completed.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] On Fri, Dec 05, 2003 at 08:05:34PM +, Henning Makholm wrote: Step 2: Packagers can now chose to supply .desktop files instead of the Debian format, with a versioned dependency on menu. I can see no reason to proceed any further than this. As far as I read this thread, the .desktop format is supposed to be able to encode more information and have better i18n than the Debian-native format. The underlying idea would be to reap the benefit of these capabilities for all packages with menu entries. There's basically two ways to do this: Migrate to .desktop or enhance the existing format. My sketch depicted the former. The idea of migration would seem to have the benefit of being directly compatible with the stuff non-Debian people produce. Absence of gratuitous differences in data formats across software and distributions is usually viewed as a Good Thing in itself; it is the Unix way of doing things, the Free Software way, and the insert-random-warm-and-fuzzy-buzzword-here way. This argument, of course, assumes that the differences between the (hypothetically enhanced) Debian syntax and the .desktop format *are* gratuitous. I don't know whether or not they are, but this thread does not seem to contain any replies to qestions of which technical advantages the Debian format has that .desktop hasn't, which would make a migration a Bad Thing, rather than just something that one personally doesn't want to spend time on. (Everyting resembling technical stuff above has been (mis)understood from this thread. I actually don't know much about the menu system; it doesn't seem to be available in a documented way to people who have their own $HOME/.fvwm2rc) -- Henning Makholm The trouble is that the chapter is entirely impenetrable. Its message is concealed behind not just thickets of formalism, but hedges, woods, and forests of formalism. There are whole pages with not even a paragraph break.
