Re: New Control Centre

[Federico Mena Quintero <federico ximian com>]

El mar, 06-02-2007 a las 10:14 +0000, jamie escribi� On Mon, 2007-02-05 at 21:19 -0600, Federico Mena Quintero wrote:
> > 
> > Now that we have hundreds of .desktop files, it is not a good idea
> > anymore to have them scattered all around the disk.  You are absolutely
> > right; the system it is built on is stupidly inefficient and broken!
> 
> Yes and its fairly easily fixed with tracker once I add .desktop file
> indexing to it

Oh, doing the caching is trivial.  You could dump the .desktop files
into a database, or you could cat them together and read a
single .big-desktop file, or you could invent
yet-another-mmap()able-format.  The storage format is pretty much
irrelevant.

But that's not the hard part of solving this problem.  The hard part is:

* How will newly-installed packages add to the cache?

* How will removed packages remove from the cache?

* What's the most convenient way for distributions to do the two things
above?  Having a --disable-desktop-file-update (analogous to
--disable-schema-install for GConf) is ugly, and doing this procedure in
the postinstall of RPMS (or your favorite packaging format) can get ugly
pretty fast.

* How do we share the cache between desktops / platforms / whatever?
(KDE, GNOME, XFCE, etc.)

* If we use sqlite, are we stuck with using a certain version of sqlite
forever?

* How do we detect/survive a corrupted cache?  We don't want the case
where you can't run *any* applications just because the cache is busted.

One interesting thing:

cacharro$ du -s /opt/gnome/share/applications
1508    /opt/gnome/share/applications

I.e. 1.5 MB.  This is *tiny*.  Maybe a database is overkill; I don't
know.  See the big wins that Michael Meeks got from simply concatenating
our .server files in bonobo-activation.

  Federico