Earlier this month I headed to Toulouse for some excellent food, KDE Itinerary field testing, and of course the yearly KDE PIM sprint. David has already written about some of the things we did there, here I’ll cover the tasks I focussed on during the sprint: upstreaming the KContacts vCard framework and the KCalCore iCalendar framework to KDE Frameworks.

KDE Frameworks

Both KContacts and KCalCore actually used to be part of the KDE Frameworks predecessors since the KDE 2 and KDE 4 era respectively (kdelibs and kdepimlibs). However during the KF5 era they initially ended up in the KDE Application release, mainly due to dependencies on legacy code like the old KDateTime classes from KDELibs4Support.

With the legacy dependencies removed since the 2017 Randa sprint, it’s finally time to get those libraries back to that level with all the KDE Frameworks guarantees on API and ABI stability. This is particularly useful for components that aren’t part of the KDE Application release cycle currently, such as Zanshin or Calindori. Following the KDE Frameworks policies makes libraries much easier to consume, while the monthly release cycle enables us to get improvements deployed quickly and continuously to our users.

To make the transition as smooth as possible for distributions, the plan is to follow the same approach that was already used previously when moving KHolidays and Syndication to KDE Frameworks. That is have one final release with KDE Application that already uses the same naming and ABI as the final framework, and then start doing KDE Framework releases, so we have a drop-in replacement for the last KDE Application release. Distributions can then transition to the framework release whenever it’s convenient for them and without impact on the depending applications.


KContacts is an implementation of the vCard standard, and has been around under the slightly less descriptive name “KABC” since the KDE 2 era in what was kdelibs back then. That history means it’s quite solid code with a stable interface, however it also means there’s some legacy that needed cleaning up before promoting it to KDE Frameworks:

  • Remove remains of the Qt2 QSortedList pattern.
  • Remove configurable behavior of operator<.
  • Fix typos in method names.
  • Remove dead code and unused deprecated methods.
  • Hide things that should not be public.
  • Fix API documentation not showing up correctly on api.kde.org.

Digging further into the code using KContacts, we found a few bits that could be moved upstream to KContacts in order to solve common use-case more elegantly or to avoid duplicated code:

  • Convenience API for commonly used non-standard vCard extensions.
  • Add method to retrieve a normalized phone number usable for dialing or tel: URLs.
  • Add a Q_PROPERTY interface for direct consumption of KContacts types by QML or Grantlee.
  • Add convenience methods for accessing type and preference parameters of more elements (emails, URLs, instand messaging addresses), replacing the need for string-based access in more places.
  • Replacing custom elements with IMPP elements for instant messaging addresses (still ongoing work at this point).

Most of the above has been integrated by now, and KContacts is waiting for review to become part of KDE Frameworks 5 later this year.


KCalCore is an implementation of the iCalendar standard, and is also around since quite some time. Compared to KContacts it’s a bit more complex due to the timezone handling and recurrence algorithms in there, but that is compensated by almost 500 unit tests. So overall the situation for KCalCore is quite similar, we also found a few legacy issues to clean up before proposing the move to KDE Frameworks:

  • Remove remains of Qt2 QSortedList-based set algorithms.
  • Remove deprecated and unused methods.
  • API documentation polishing.
  • Ensure that all public types have a d pointer.

A few more still to be done tasks have already been identified as part of the ongoing review thread, such as splitting KCalCore::Attendee and KCalCore::Person into two simple value types, or to find a more elegant solution for the remains of the Akoandi::SuperClassTrait in there.


You can of course help by reviewing (and improving) those two new frameworks to get this done. But more importantly I’d like to encourage everyone to look for things around you that actually should be in KDE Frameworks, so we can all share the benefits and don’t have to duplicate development or maintenance efforts. This could be little things like a CMake find module that is used in multiple places (and therefore probably should be in ECM), useful methods for existing classes, additional classes, or even entirely new frameworks.