Fun with Akonadi Dataengine

[David Baron]

On Wednesday 18 February 2009 04:35:50 Sebastian Kügler wrote:
> Hi David,
>
> On Tuesday 17 February 2009 21:47:46 David Baron wrote:
> > On Tuesday 17 February 2009 22:01:18 David Baron wrote:
> > > Latest from playground SVN.
> > >
> > > I re-downloaded and compared with the older code. The only real
> > > difference besides the volume of diagnostic printout is that the
> > > ContactCollection-# list is made at a completion event rather than
> > > immediately on
> > > connectSource(ContactCollections).
>
> That should work as expected now.
>
> > > Such could alleviate some of the panel delay I encountered when doing
> > > this directly in init(). However, this is a small amount of data at
> > > this point. The delay was more from the log-jam on kde/plasma startup.
> > > For example, with the older dataengine, it took almost 90 seconds
> > > before I got the contacts to start dataUpdate-ing. Later on, run from
> > > the plasmoidviewer, this same thing completes in several seconds.
>
> Just comment out the kDebug() lines that generate this. I've commented out
> and removed most of it.
>
> > > With the new code, I will not have any useful return from query until I
> > > have the equivalent in dataUpdate. This is why it did not work. I
> > > should recode it so it would work either way.
> >
> > To get it to "work" either way, I still use the QTimer.  I MUST repeat
> > the connectSource( ContactCollections ) or a least wait the second before
> > the 1st call since the console shows no further such calls. When I get
> > dataUpdated from this call, I connect the ContactCollection-#,, and then
> > have the QTimer call connectAllSources and I get my contacts.
>
> I've re-read the API docs and found a note that setData() needs to be
> initialized with empty data when we return true there. I've committed that
> change, it makes it work as expected now. I've also added sources() to the
> engine which makes it easier to find out what to do with it.

This would explain why I needed to seemingly repeat the calls (and why I could 
not use sources() ). SO if my timer works on the first try, so good. I'll get 
rid of it when things zip along the first try.

>
> I've also found a weirdness (expectedness?) in the dataengine. Apparently,
> I cannot connect to sources from different classes, somehow everything ends
> up calling the dataUpdated() in MailExtender, while I connect to the source
> "EmailCollection" from the applet itself (LionMail). For now, I'm just
> relaying the data in that case and call dataUpdated() in the applet using
> it. Still, something to keep in mind.

And this explains why doing things in a background thread did not work.

> > HOWEVER, the new code will crash the applet in plasmoidviewer just as it
> > crashed the explorer. This may be due to the increased volume of
> > "printed" contacts information or it may be something else. The applet in
> > the panel apparently did not crash (the desktop and panel came up) even
> > though the "plasma" command certainly showed all that stuff. In any
> > event, I am going back to the older code until the problem is resolved
> > since I cannot test the applet or dataengine with the new code.
>
> Do you have a backtrace for this crash?

I svn up and retry that today.

> BTW, thanks for your patience in getting it sorted how we want the akonadi
> engine to behave. As Aaron said, we should design it for actual usecases,
> you happen to be the first (well, second ;)) one to come across this, hence
> the immaturity of the akonadi engine.
Thanks, enjoying it.
>
> I had a chat with some of the Akonadi people tonight, giving me some more
> perspective of where we can go. Something I'd like to have is "give me the
> contact for this email address" (or telephone number, in your case), but
> Akonadi doesn't support this yet. Something that could be considered
> together with more Nepomuk integration in Akonadi, as I was told.
A lot of functionality is buried in akonadi which is why the dataengine code 
is so simple. Nice idea but to do something outside of their functionality, 
one needs to build a local data structure which is what I do. Email addresses 
should be one-to-one (of course, folks can share 'em like my wife and me!). 
Phone numbers are many-to-one by definition (home, work, mobile, fax, etc.). 
QLIstWidget keyboardSearch works on the leading text, case insensitive while 
its sort is case sensitive, in any case, usable.

As I have stated, for folks to make use of akonadi and nepomuk, these things 
need to run nicely niced in the background. To be able to use kde4, I either 
manually renice a lot of this or let and do it its intervals.