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
