On Fr, 2011-04-29 at 19:12 +0100, Dumez, Christophe wrote: > Hi, > > Please find attached two patches I wrote to address the following open work > item: > * 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
To put this into perspective, the goal is to have one MeeGo vCard flavor that all apps running on MeeGo understand, regardless whether they use EDS or QtContacts. For example, a mail program could import/export vCards in email attachments and store it so that Evolution understands them when talking to EDS directly. All QtContact using programs will pick up the MeeGo vCard flavor by loading the com.meego.edscontacthandler automatically; no need to change their source code. The format used for vCard extensions was meant to be this: * X-EDS-QTCONTACTS:<detail>;(<field>;<encoding>;<serialized value>)* * * <detail> = detail name * <field> = field name * <encoding> = as in backup plugin (BOOL/INT/UINT/DATE/TIME/DATETIME/STRING/VARIANT) * STRING = QString as UTF-8 string, with special characters escaped * as in N * VARIANT = anything else, including byte arrays This was copied from similar code in SyncEvolution, which was inspired by the backup/restore handler. Splitting between <detail>, <field>, ... was meant to be done using a vCard compound value type. It turned out that extensions cannot currently use that type because QVersitReader only knows about a hard-coded list of properties with that type and won't parse a compound type correctly in other properties: http://bugreports.qt.nokia.com/browse/QTMOBILITY-1298 Therefore right now, both SyncEvolution and this plugin use ^ as separator and do the splitting themselves. This is extra work and makes the encoded extensions look really weird. In QTMOBILITY-1298 I suggested to add a new API call. But that won't be enough for apps picking up com.meego.edscontacthandler, because they wouldn't invoke that call on their reader instance. Looks like a system configuration mechanism for property types or a general-purpose plugin concept for QVersitReader/Writer will be needed. Mika, what do you think about this and the bug reports below? Any chance to get this into 1.2 final? BTW, should we cross-post to the QtMobility list or keep this meego-dev only? > A test program is also included in the second patch to make sure the mapping > works. > > Note that while implementing this, I stumbled upon a few small problems in > QtMobility 1.2beta0 (QtContacts and QtVersit): > http://bugreports.qt.nokia.com/browse/QTMOBILITY-1592 > http://bugreports.qt.nokia.com/browse/QTMOBILITY-1590 > http://bugreports.qt.nokia.com/browse/QTMOBILITY-1589 > > I proposed patches for all 3 (attached to each bug report). > > The plugin implementation currently works around the first 2 problems. > However, there is no clean way to do it for the last one. This causes > the QContactGeoLocation detail to have its latitude/longitude reversed > when saved by the manager. The corresponding check is currently > disabled in the test program. > > I would appreciate if you could review the patches and give me your feedback. I merged them into master, with some minor cleanups: * hard-wrapped git commit messages * added standard LGPL copyright header to new files * fixed versitplugin/versitplugin.pro (install as libqtversit_edshandler.so, not as libqtversit_backuphandler.so; avoid hard-coding paths which can be found via pkg-config), added test/edspropertymatching/edspropertymatching.pro We should move the top-level source files into a "src" directory and add qmake sub-project .pro files as needed (top level, "test" dir). Regarding the first patch, in the future it would be better to split independent aspects into different patches. In this case the workaround for QTMOBILITY-1592 could have been a separate patch that would be reverted once the fix is in QtMobility. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Open Source Technology Center Pützstr. 5 Phone: +49-228-2493652 53129 Bonn Germany _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
