Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 08:01:31 David Baron wrote: 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(). Have you tried connecting to ContactCollections, and then checking for data of this one in dataUpdated()? This would be non-blocking. (Fetching the collections is pretty fast here, so I wouldn't have thought it's necessary.) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 14:13:10 David Baron wrote: On Tuesday 17 February 2009 14:37:11 you wrote: On Tuesday 17 February 2009 08:01:31 David Baron wrote: 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(). Have you tried connecting to ContactCollections, and then checking for data of this one in dataUpdated()? This would be non-blocking. (Fetching the collections is pretty fast here, so I wouldn't have thought it's necessary.) This is what I am doing. This gives me one (more?) ContactConnection-#. It is connecting to this, oro mre accurately, its contents that needs the QTimer. Doing the initial connect was put in the timer because otherwize, it delayed the panel from coming up. Some more: - if you run 'plasmaengineexplorer --engine akonadi', how long does it take to start up? (instantly or a couple of seconds?) - if you request the source 'ContactCollections', how long does it take until it returns results? - I've just made the fetching of the collectionlist async as well, can you svn up and recompile the akonadi dataengine to see if that helps? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Tuesday 17 February 2009 17:41:38 Sebastian Kügler wrote: On Tuesday 17 February 2009 14:13:10 David Baron wrote: On Tuesday 17 February 2009 14:37:11 you wrote: On Tuesday 17 February 2009 08:01:31 David Baron wrote: 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(). Have you tried connecting to ContactCollections, and then checking for data of this one in dataUpdated()? This would be non-blocking. (Fetching the collections is pretty fast here, so I wouldn't have thought it's necessary.) This is what I am doing. This gives me one (more?) ContactConnection-#. It is connecting to this, oro mre accurately, its contents that needs the QTimer. Doing the initial connect was put in the timer because otherwize, it delayed the panel from coming up. Some more: - if you run 'plasmaengineexplorer --engine akonadi', how long does it take to start up? (instantly or a couple of seconds?) Program comes up quickly - if you request the source 'ContactCollections', how long does it take until it returns results? And I get this quickly These two connections are quick enough. However, when plasma is first starting up, everything has slowed down. Maybe this is why my 1 second delay simply lets everything start up nicely. It is all the contacts that might take several-10 seconds to come up in the explorer and in the program. The explorer is blocked during this wait. I seem to need to see them all listed in the console before any dataUpdate's are called. This is most probably the change you cite below. Maybe I do not really (or always) need to repeat my connectAllSources but the .h file says doing so is harmless . - I've just made the fetching of the collectionlist async as well, can you svn up and recompile the akonadi dataengine to see if that helps? Most probably will. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
Latest from playground SVN. After hand entering stuff like akonadi/monitor.h since I do not have the Akonadi/Monitor files available, it build OK. My applet's sequence no longer gets to 1st base. I do not get the query() that gives me the ContactCollection-#. In the explorer, I do get it. Possibly connectSource works and Query is broken! When I request it, I see in the console contact data items rather than sources and then the explorer crashes. I most likely do not want ALL the hash items all at once like that. What I had been getting in dataUpdated was the source (Contact-) and the data-hash. Will I still get this (and the console output has changed) or is this all changed as well. If so, I think the former sequences made more sense. Since I had contacts one-at-a-time to work with rather than having to parse when I have a new one. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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). 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. 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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). 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. 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. 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. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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. 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. 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? 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. 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. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Software signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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. 2. At 1st timeout, I do the a query(ContactCollections) then if I find a suitable key, connectSource, i.e to ContentCollection-6. 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. 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?). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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? 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? 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 Why in one-second intervals? Is it blocking for you otherwise? 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. Well, what exactly is it that you actually want? :D 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. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
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 :-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine
On Thursday 12 February 2009 17:49:10 David Baron wrote: Got to try it. Cool :) connectSource to ContactCollections. dataUpdated() is called and I connectSource to ContactConnection-# that it gives me in the data.uniqueKeys() Yup, that's how it's supposed to work. dataUpdated() is never called again. The console shows all the contacts being added int but the program never sees them. So you say that the data you receive in dataUpdated() is empty, or lacking? Can you show your code? 1. What do I do now? 2. How do I know when all the data has been loaded--no more calls to dataUpdated() are going to happen? You never do. Contacts can be added (and removed) all the time. Note that the monitoring probably doesn't work yet, I only wrote that part on the flight last Tuesday, but didn't get to actually try and test it. When you get dataUpdated(), however, you are sure that that part of the data can be used (and is done loading). -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fun with Akonadi Dataengine (solved)
On Friday 13 February 2009 10:30:22 David Baron wrote: Got to try it. connectSource to ContactCollections. dataUpdated() is called and I connectSource to ContactConnection-# that it gives me in the data.uniqueKeys() dataUpdated() is never called again. The console shows all the contacts being added int but the program never sees them. 1. What do I do now? 2. How do I know when all the data has been loaded--no more calls to dataUpdated() are going to happen? You can do an initial loading with dataengine()-query(), and then use only connect to the sources you're actually interested in. Calling connectAllSources() OUTSIDE dataUpdated() worked. Makes sense since this one could have fun consequences if it worked inside :-) Don't connectAllSources() when you only need a few, you can load the data when you actually want to use it, that way you prevent slow starting up. Since things are asynchronous, knowing when the data is loaded is desirable but hundreds of contacts loaded in a second or so on my clunker so I cannot complain. It could be a bit disconcerting, however, to see a listbox filling and sorting live so knowing when to actually (fill and) show it is desirable. So such a signal may be placed on the wish list. What's the problem with it filling? If it keeps moving this way, you could for example wait with adding new items when you You don't need to use only dataUpdated() btw, you can just query() dataengine, and pre-populate your widgets that way. This is actually what I'm doing in Lion Mail's createConfigurationInterface(). Afterwards, I assume a dataUpdated call implies an item was changed inside or outside the applet so this item would need updating in the visualization as well. The applet is the visualization, and dataUpdated() *is* that notification you seem to be looking for :) At least now I can design my interface for viewing and using those contacts. A big congrats for job well done. When will it be released? Didn't think about it yet. Guess we should do a bit more testing (especially monitoring, see my other email). Another thing is that most people don't have their contact data in Akonadi yet. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
