On Wed, Dec 10, 2003 at 01:28:51PM -0700, Bruce Sass wrote: > On Tue, 9 Dec 2003, Henning Makholm wrote: > > Scripsit Bruce Sass <bsass@edmc.net> > > > 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 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. Chris
Attachment:
signature.asc
Description: Digital signature