Hi, Please find attached two patches for QtContacts EDS backend: 0001: Make the QContactAbstractRequest::start() method return a boolean so that the caller knows when an error occurred and the request could not be started. 0002: Make the QContactFetchRequest and QContactLocalIdFetchRequest really asynchronous to improve performance. Tests were updated to check the functionality.
The only supported asynchronous request that still runs pseudo-asynchronously is the QCOntactDetailDefinitionFetchRequest because it would not help. This is a fast and ultimately synchronous operation anyway. I have a question for you Patrick. Is there a reason to keep the "#ifdef SUPPORT_HASH" everywhere in QContactEBook? The hash support code is no longer needed due to your EDS id patch afaik and this code is outdated anyway. I ask because it would really make the code more readable if I could get rid of this part. Kr, Christophe Dumez. -----Original Message----- From: Ohly, Patrick Sent: Thursday, April 21, 2011 5:16 PM To: MeeGo-dev Subject: QtContacts/KCal-EDS Hello! I got permission to publish the bridge code between QtContacts resp. KCalCore and EDS. Sorry for the delay, I had to take care of some other business first. The code is now here: http://meego.gitorious.org/meego-middleware/qtcontacts-eds http://meego.gitorious.org/meego-middleware/kcal-eds There's also an overview diagram in the Wiki showing the key difference between the two approaches: http://wiki.meego.com/images/Qtcontacts-kcal-eds.png The difference is that QtContacts allows plugging a new backend into the existing API. KCal doesn't allow that: an app needs to reference some additional class, using their specific API, to load and store a calendar. mKCal is one such additional API. I thought a bit about emulating that API, but eventually decided against it because much of that API is by design mKCal specific and wouldn't translate well to EDS (example: the notebook concept). QtContacts-EDS ============== This is derived from the Maemo 5 contact manager. The code wasn't very clean to start with (IMHO, for example aborting the process on errors) and uses a extra private implementation class which I find unnecessary. Usually that is done to ABI compatibility, but the only public interface in this case is the QtContacts plugin API, which remains stable even if just one class is used. I kept the structure for now, to document how individual aspects of the code can be translated back to upstream EDS. Long term I'd like to see QContactEBook and QContactEBookEngine merged. Code quality aspects aside, right now reading/writing and change notifications work. To install qtcontacts-eds, compile it and ensure that /usr/lib/qt4/plugins/contacts/ has the resulting .so (or a symlink to it). It depends on a patched EDS, see below. To use the new storage, use "eds" as manager name. There is a test program for the change tracking included. Manipulating data in EDS can be done via Evolution or the SyncEvolution command line: http://syncevolution.org/blogs/pohly/2010/manipulate-evolution-kcalextendedmkcal-qtcontacts-pim-items-uniform-command-line To access EDS via QtContacts-EDS in the SyncEvolution command line, use the following "database" value for syncevolution backend=qtcontacts \ database=qtcontacts:eds:source=local:/system \ --print-items \ @foo bar Never mind the "@foo bar" part, the values don't matter in this context. Open work items: * add a QtVersit formatter which A. maps QtContactDetails to the corresponding properties as used in EDS B. loads/stores arbitrary QtContactDetails as X- extensions, similar to the SyncEvoQtContactsHandler in [1] * refactor the code (rewrite from scratch?), add error handling, consistent resource tracking (RAII as in SyncEvolution and KCal-EDS [2]?) * have Evolution maintainers review the EDS patch (attached) that QtContacts-EDS depends on (no mapping between int32 QContactId and traditional EDS string ID) and get it into MeeGo [1] http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/backends/qtcontacts/QtContactsSource.cpp [2] http://meego.gitorious.org/meego-middleware/kcal-eds/blobs/master/src/gnome-support.h KCal-EDS ======== This code was written from scratch. It currently supports reading from EDS, but not writing. Change notifications work on a per-item level by updating the opened calendar with changes made in the underlying EDS. This is an improvement over mKCal, where apps currently need to reload the whole calendar each time the database changes. Open work items: * add writing * clarify endDate() semantic My plan is to look into that next week. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
0001-QContactAbstractRequest-make-start-method-return-a-b.patch
Description: Binary data
0002-Engine-Make-contact-fetching-requests-really-asynchr.patch
Description: Binary data
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
