Fun with Akonadi Dataengine

David Baron d_baron at 012.net.il
Tue Feb 17 08:01:31 CET 2009


On Tuesday 17 February 2009 00:44:13 Sebastian Kügler wrote:
> On Monday 16 February 2009 19:42:03 David Baron wrote:
> > On Monday 16 February 2009 19:08:03 Aaron J. Seigo wrote:
> > > On Sunday 15 February 2009, David Baron wrote:
> > > > 1. The ContactCollection-# loads all the contacts but they are not
> > > > necessarily accessible at this point. I might have to try
> > >
> > > hm; this sounds rather inefficient for large address books. perhaps
> > > it's a good idea to collect use cases for this part of the engine and
> > > build specifically for those rather than build something too general
> > > purpose; the engine doesn't need to be able to support building an
> > > entire address book application around it (that's not the point of
> > > engines), so defining what a widget should like to do with it is
> > > probably a good start point.
> >
> > It's a point. But I am dialing the phone. Here is how I do it now:
> >
> > 1. In init(), I start a QTimer with 1 second interval.
>
> If you need to use a timer here, I think something's wrong. You should be
> able to just connect to dataUpdated() for that collection and
>
> If it's necessary to use a timer, there's something wrong with the
> interface. It should be completely event-based, no?

The problem I found is (maybe because ContactCollection-# loads other sources 
rather than its own data-hash) is that until all the individual contact 
sources have been loaded into the engine (shown on console messages if I am 
running in the plasmoidviewer), connectAllSources does nothing. It needs be 
repeated when sources are in fact available. I am not saying it SHOULD be this 
way but that it how I find it to be.
>
> > 2. At 1st timeout, I do the a query("ContactCollections")
> > then if I find a suitable key, connectSource, i.e to ContentCollection-6.
>
> You can just do that in or from init(). Why use a timer here?
The panel on which the applet is nested delays coming up when I do it directly 
in init().
>
> > 3. After that, I connectAllSources at 1 second intervals until
> > dataUpdated gets called. At this point, I stop the QTimer and am now
> > receiving the contacts. Using these, I assemble my phone book into a
> > QListWIdget.
>
> You should query ContactCollections and then in dataUpdated(), you check if
> the source is
I query to get the ContactCollection-# key and then connect to that which 
initiates the load of all the Contac-# sources after a delay.
>
> Why in one-second intervals? Is it blocking for you otherwise?
I could have used another interval. The point is that I am NOT blocking so 
everything plays "naturally."
>
> If you're unsure how to do it, you can look at lionmail.cpp. There, it
> should be async and pretty similar to what you want.
URL? 
>
> Well, what exactly is it that you actually want? :D
To build a phone number directory from the contacts. One contact may give me 
several entries. All easy by checking the keys.
>
> > This works nicely in the background without delaying the panel/desktop
> > and the GUI stays live. Using a QThread was my 1st try but the dataengine
> > did not like that. The QTimer looks like a thread but is done differently
> > so this plays.
> >
> > The alternative of writing a dataengine tailored to this type of task
> > such as was done in a birthday plasmoid could be considered, not using
> > Akonadi. Unless these background daemons are tactfully niced, I think
> > folks may uninstall them. Nepomuk and all the Akonadi children take a
> > large bite of CPU, especially after login. They may quiet down a lot
> > later on (after everything is sync'ed?).
>
> Yeah, that is indeed a problem of all data-intensive services. It is also
> why it's all the more important to have display of data fully async, and
> not depending on complete initialization of all data on startup.
The QTimer let me do exactly this (while a simple background thread did not). 
If there be a more correct way, easy enough to try it out :-)


More information about the Plasma-devel mailing list