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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel