Re: SoC idea: desktop file cache

[Martyn Russell <martyn lanedo com>]

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.

--
Regards,
Martyn