Re: SoC idea: desktop file cache

[Adrien Bustany <abustany gnome org>]

On Mon, 28 Mar 2011 09:07:36 +0100, Martyn Russell wrote:
> On 25/03/11 03:22, Colin Walters wrote:
> > Bugzilla is down or I'd write this there, and it's a bit lengthy to
> > fit in the SoC wiki page, so I'll just post here and link from the
> > wiki.
>
> Hi,
>
> > == Kill gnome-menus ==
> >
> > gnome-menus is the library which reads all this stuff presently, and
> > it has one serious drawback:
> >
> > * It is entirely synchronous
> >
> > This especially hurts since we have to read applications from
> > gnome-shell, which is the compositor - a blocked compositor means no
> > redrawing.
>
> Sounds like a god idea.
>
> At this point, I would like to just mention that Tracker already
> mines applications and it is REALLY fast at this. On my desktop here
> it takes a few seconds to store all information about all 
> applications
> installed.
>
> > There are other, more minor flaws:
> >
> > * It is quite inefficient; there is a ton of string allocation going 
> > on.
> > * It's not threadsafe (see e.g. the static GSList     
> > *pending_events
> > in menu-monitor.c)
> > * It wasn't designed for introspection (
> > https://live.gnome.org/GObjectIntrospection )
>
> Tracker has introspection support in a branch right now and should be
> merged to master in the coming week or so.
>
> > == Implementing a saner tool ==
> >
> > 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.
>
> Tracker uses tracker-miner-fs currently for this. We've been meaning
> to split it into a separate miner for applications and there is a bug
> about it. Also, this works for Qt/MeeGo applications too.
>
> > How do you implement a mmap'd file?  Take a look at how dconf does 
> > it:
> > http://git.gnome.org/browse/dconf/tree/gvdb
>
> We use gvdb internally in Tracker already for fast db ontology look
> ups and SQLite of course as the db backend ;)
>
> > The next question is how does the cache get rebuilt?  I think we
> > basically need a system service with an inotify (GFileMonitor) watch
> > on all those directories, and it takes care of rebuilding it.
>
> Tracker uses GIO which uses inotify or the next best thing (there are
> others supported) depending on the target platform. So this is 
> already
> covered in Tracker.
>
> > The library api could simply be:
> >
> > void on_desktop_cache_changed ()
> > {
> >    DesktopCacheEntryIter iter;
> >
> >    desktop_cache_iter_init (cache,&iter);
> >    while (desktop_cache_iter_next (cache,&iter)) {
> >      g_print ("desktop file path: %s\n",
> > desktop_cache_iter_get_desktop_file_path (&iter));
> >      g_print ("desktop name: %s\n", 
> > desktop_cache_iter_get_desktop_name (&iter));
> >    }
> > }
> >
> > DesktopCache *cache = desktop_cache_get();
> > g_signal_connect (cache, "changed", on_desktop_cache_changed, self);
> > desktop_cache_read_async (cache, on_desktop_cache_read_complete, 
> > self);
> >
> > The library would simply have an inotify watch on the cache file.
> > Which should probably simply be defined to live in
> > /usr/share/applications/applications.cache, say.
>
> libtracker-sparql is a thread safe, async and sync library which has
> notifications for updates already available. You could just use that
> in your application to listen to specific changes.
>
> > Filtering the menus by category would live in a higher layer, in my
> > case, gnome-shell probably.
>
> Adrien Bustany wrote a patch that integrates Tracker with GNOME shell
> last week and with any luck it should be merged into master soon.
>
> So, my suggestion is to use Tracker here, otherwise we're just
> duplicating work.

That said, if we use Tracker we don't solve the problem in a
cross-desktop way... Still worth considering though.

Cheers

Adrien