Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
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
> > > 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
Reply to: