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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
