Re: SoC idea: desktop file cache



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]