From Qt Wiki
Revision as of 17:12, 6 January 2017 by EdwardWelbourne (talk | contribs) (Categorize)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

Qt Pim session

Session host: Cristiano di Flora

Session preliminary topics.

Please add here any topics you would like to discuss together at CS 2012 about Contacts, Organizer, or Versit API as well as ideas for brand new APIs to be added to extend Qt's Personal Information Management API portfolio.

  • Main functionality of each API (QtContacts [doc-snapshot.qt.io], QtOrganizer [doc-snapshot.qt.io], QtVersit [doc-snapshot.qt.io])
  • Key differences between old QtMobility APIs and Qt 5.0 PIM APIs
  • QtPim APIs beyond 5.0 (extensions to existing APIs, new APIs)

Agenda and notes from the session

Key differences between old QtMobility APIs and Qt 5.0 PIM APIs

Details / Fields system

  • From String-based representation to Enum values
  • No mutable schemas anymore
  • Added ExtendedDetail detail class as simpler mechanism for clients to store custom details


  • From String based to dedicated Class (to be specialized by engine implementors….same as in Organizer)


  • From ID-based to QContact-based interface


  • Removed "dynamic properties" mechanism
  • New Features added to model API
  • Performance improvements to Contact model implementation

Future Work


  • TimeZones support(!): Coming to QtBase on 5.1. Everybody contributing to Organizer need to follow it up and there is room there for contribution from Organizer contributors as well


  • Improve support for social networks / social data
  • Aggregated contacts / concept of "Persona"

Common (C++ APIs)

  • Observer / Watcher class separated from Manager (QContactManager, QOrganizerManager)

Common (QML APIs)

  • Create more narrow-scoped models
  • Remove Manager logic from model elements and create new "Manager" elements for each API
  • Add support for batch save operations
  • Improve memory consumption
  • Error codes from String-based to Enum values
  • improve documentation

Backends(!) needed

  • OSX
  • KDE pim: Kde pim is having support for handling the opposite use case (mapping QtPim data to kde-pim). For QtProject would be beneficial to do this the other way around (having kdepim- QtContacts and QtOrganizer backend plugins). This should be discussed and designed / agreed via mailing list + gerrit + irc.