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

[Bruce Sass <bsass@edmc.net>]

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) takes less
> than 10s on an Athlon 600, which is about a 5 year old system.

I don't know about an Athalon 600, but I do know that my P133 is
little more than a paperweight for many minutes while menues are being
generated (and parts of KDE freeze for an annoyingly long time
afterwards while kbuildsycoca runs, but that's what I get for running
KDE on a P133 :-), and it don't want to see how much worse it could
get by including i18n and stuff to support freedesktop features in
all menu entries irregardless of whether a WM which supports them
is installed or not.

> > > > 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 info in
> kcmaccess.desktop for example it goes from 14027 bytes to 429 bytes. The
> very large ones (> 4KB) seem to all be for KDE's control panel, which
> aren't regular apps. By the way anything under 4KB is still 4KB in most
> cases anyway due to fs blocksize, so arguing about whether something is
> bloat that is under 4KB is pointless. I ran find on my KDE cvs checkout
> and the normal size seems to lie between 1.0-3.0KB which is still under
> the fs blocksize.

What you are forgetting is that those who will be impacted the most
are also most likely to be (as you pointed out) running relatively
small harddrives... 1024 byte blocks, or bloat on the order of 2-3
times what is necessary from a filesystem point of view?  Are there
not newer filesystem (e.g., reiser) in which the bloat would be equal
to the actual byte count difference?


> Breakdown
> ---------
> 167    0 < 1024
> 538 1024 < 2048
> 355 2048 < 3072
> 71  3072 < 4096
> 173 4096 < ...
>
>
> Also, notice that Debian only has 1935 menu files in total and already
> has 2625 desktop files. A lot of those menu files are manual conversions
> of desktop files!  This is another good reason to convert to desktop as
> Debian's default for menu system.

What you are saying here is that KDE and Gnome have lots of apps, so
Debian's default menu system should bend to their will... that, imo,
is not very Debian-like, if it was there would not be 11 supported
architectures, ports to NetBSD and HURD, and well over a dozen menu
data consumers besides KDE and Gnome.


I don't want to see the bar raised with respect to what constitutes a
usable small Debian system as a result of catering to a subset of
packages, especially when there are ways around it.


<sarcasm>
Sorry about the length of this post, but, hey, most people have
capable boxes, lots of harddrive space, fast 'net connections, etc...
so what does it matter, eh.
</sarcasm>


- Bruce
 (putting on an asbestos suit because he expects to get slammed
  for that last remark, but figuring it is worth it if it serves to
  drive the `wasted resources' and `just because a lot use it
  doesn't make it the way to go' points home)