Re: SoC idea: desktop file cache

[Nirbheek Chauhan <nirbheek gentoo org>]

Hey everyone,

On Sat, Mar 26, 2011 at 12:25 AM, Martin Pitt <martin pitt ubuntu com> wrote:
> Colin Walters [2011-03-25 12:18 +0100]:
>> == Desktop File Cache ==
>> There are multiple ways to approach this, but I think by far the
>> simplest is just an mmap'able file containing all .desktop files found
>> in the desktop paths.  Don't try to implement all the merge logic,
>> etc.
[snip]
> I played aorund with various file formats, and actually
> found that with gnome-menus a simple GKeyFile actually worked best,
> since in the end we want to read all the relevant desktop files
> anyway, and reading them linearly out of the file cache into the
> internal DesktopEntry tree representation was fine.
[snip]
>> The next question is how does the cache get rebuilt?
>
[snip]
> So we went for the pragmatic solution and only do caches for
> /usr/share/applications. (The patch above works with any desktop
> directory, but we only build cache files for that one). We have a
> script [3] to build the cache, which gets run by the package manager
> whenever a package adds/changes/removes/modifies files in
> /usr/share/applications/. (In dpkg terms this is called a "trigger").
> So we only have some extra overhead at package install/upgrade time
> (which is already slow enough, so that the extra second doesn't
> matter), but no extra overhead at runtime.
>
> This concept is very hard to generalize as an upstream solution, of
> course. The gnome-menus patch [2] and the script [3] aren't distro
> specific at all, but the concept of package triggers simply doesn't
> exist with upstream tarballs, and thus there will always be some
> distro specific integration here.
>
> Also, I'm well aware of the corner case that this would simply ignore
> desktop files that the admin puts into /usr/share/applications/. We
> currently treat this case as "don't do that then", that's what
> /usr/local/ is for, but it's of course a small design wart of this.
>

I was thinking that this is the kind of problem that has cross-desktop
implications, and so I wondered how KDE solves this problem. We should
probably take their feedback on this?

On the other hand, I think there is a way to do this in a
cross-desktop fashion with existing infrastructure as well.

We already have `update-desktop-database` for updating the MimeType
cache from desktop files, and that's supposed to be run after any new
.desktop files are added to $XDG_DATA_DIRS/applications, so I was
wondering if caches for the other properties could also be generated
by the same tool at the same time?

Of course, we'd have to come up with a format for that, but I think
the GKeyFile format that the Ubuntu folks have come up with could be
reused since the mimeinfo cache is a GKeyFile as well.

As I understand it, this would be equivalent to the Ubuntu solution,
would be applicable as an upstream solution, and would be useful for
other DEs as well. Since we have the time, this should be very doable
in time for 3.2.

Cheers,

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team