zeitgeist team mailing list archive

[Jason Smith <jason.smith@xxxxxxxxxxxxx>]

On Fri, 2009-11-20 at 07:48 +0100, Mikkel Kamstrup Erlandsen wrote:
> 2009/11/19 Jason Smith <jason.smith@xxxxxxxxxxxxx>:
> > Zeitgeist Developers,
> >
> > There is an amazing amount of activity surrounding the happenings of
> > Zeitgeist. Lots of excitement going on and obviously Zeitgeist will
> > continue to be an important part of the linux experience in the coming
> > years. Zeitgeist has not been without issues, there have been two major
> > ones I can think of.
> >
> > - The API is too complex
> > - The information quality is fairly low without lots of item providers
> >
> > The API issue has been largely addressed with the 0.3 release and I hope
> > the API can be stabilized almost completely at this point. The
> > information quality issue has also received considerable attention,
> > however I believe more can be done.
> 
> I think you are right about this, and it is basically also what we
> agreed on in the hackfest.
> 
> About the Zeitgeist API I actually think the new API is pretty sound
> (at least InsertEvent, GetEvent, and FindEventIds - we have not worked
> a lot on the last parts of the API). Just yesterday we landed a branch
> of mine adding a client lib (in Python for now) on top of the DBus
> interface. I think that it makes it pretty much as easy as it gets
> (modulo the fact that there are no sync methods in the API, only
> async; synchronous methods are made of evil).
> 
> When we have some more experience with the client API in Python I'll
> start on a client lib in C/GObject. It is my hope that I can line it
> up with the inclusion of GVariant+GDBus in GLib, but I don't intend to
> block on it if the inclusion drags out.
> 
> > In short I believe the problem with Zeitgeist is it works largely at the
> > application level. Getting individual applications to provide
> > information to Zeitgeist, or watching applications through wnck.
> > Instead, I believe a lot more can be achieved at the toolkit level with
> > a relatively small patch (or perhaps set of patches) to GIO and
> > libgnome-desktop.
> 
> Indeed! I am glad you bring this up. I have been wanting to go down
> that route myself for a while - like hooking into GtkRecentManager
> etc. I have not looked much into it because we have been busy
> finalizing the API though.
> 
> > By patching these parts of the toolkit, we can be notified easily of
> > every file the user intentionally opens, every applications they launch,
> > every process they use, quickly and efficiently with very little code. I
> > have attached a GIO patch that adds a new extension point into GIO that
> > allows a loadable GIO Module to track all launches of .desktop files.
> > This patch is early and should be considered beta quality, however it
> > provides the needed interface to begin writing a GIO module that will be
> > extremely useful to Zeitgeist. I have also included a skeleton (and very
> > quickly written) GIO module that essentially does nothing using this
> > extension point.
> >
> > I believe there to be good reason to look into getting this patch
> > upstreamed, and I believe it can be done in a reasonable time frame. The
> > benefit to Zeitgeist really could be amazing.
> 
> I had a quick look at the patch and it looks pretty solid. I have not
> found the time to take it for a test spin though.
> 
> I think it could be a good idea to write down a list of things we want
> to hook into in the lower levels to find out just how much hacking we
> need done to get to Zeitgeist nirvana. Off the top of my head I can't
> come up with anything more than app launching and GtkRecentManager,
> but it needs some more thought[1]. Then there are application level
> plugins off course, we track those on
> https://blueprints.launchpad.net/zeitgeist/+spec/zeitgeist-external-dataproviders.
> 

Mikkel

With regard to your weariness to using GIO to track IO, I think you are
very prudent. The reason I chose to hook into .desktop file launches is
that this will also get fired when you do something like double click a
document in nautilus since it goes out and finds the default application
and launches it through the .desktop file. Basically this is the awesome
side effect of getting exclusively user initiated IO.

GtkRecentManager would be interesting but I think we should push for one
patch at a time. After looking over my patch again I think it needs a
quick modification to also provide a list of the uri's that the .desktop
file was launched with. A simple oversight to be sure, but still
something we should fix.

I hope we can begin to push this patch for upstream inclusion very very
soon so that we can get zeitgeist using it even sooner.

Jason Smith <jason.smith@xxxxxxxxxxxxx>