Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries

[Bruce Sass <bsass@edmc.net>]

On Thu, 11 Dec 2003, Henning Makholm wrote:
> Scripsit Bruce Sass <bsass@edmc.net>
> > 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