Last weekend would have been the traditional annual KDE PIM meeting in Toulouse, but with travel being largely shut down in Europe we had to do this virtually. That meant missing out on the culinary treats of being in France, but we got a few things done nevertheless.

Discussions

You can find the detailed notes in the wiki, here are some of the highlights:

KCalendarCore plugin system

Nico has been working on this, eventually enabling platform calendar abstraction behind the KCalendarCore API. So the same application code could be using a calendar from Akonadi on a desktop system and the Android calendar on a phone.

We hopefully managed to sort out the remaining conceptual questions for this (modeling hierarchies, lazy population of expensive calendars, separate classes for the calendar metadata or not).

Moving PIM modules to KDE Frameworks

KDAV is nearing completion for transitioning to Frameworks after the 20.04 release (so in May or June). A final review pass resulted in a few more improvements and API cleanups.

Following KDAV the possible candidates are the KGAPI library, which is already used externally and thus would benefit most, as well as the various email frameworks (MIME, IMAP, SMTP).

KF6/Qt6 porting and future-proofing

The biggest remaining issue is the Kross usage in the account wizard. There’s three possible strategies:

  • Replace the account wizard usage by a KAccounts based solution.
  • Port the scripted UI part to QML/JS.
  • Port the scripted UI part to a widget-based plugin system.

The KAccounts based approach would be preferable, the other two options are the fallback plan in case we don’t get that done in time for the KF6 transition.

A less severe issue is the KParts usage in Kontact, David has meanwhile largely completed its port to the embeded JSON based plugin loading.

Phasing out the Kolab resource

There’s a better maintained approach to access Kolab servers nowadays, with a combination of an IMAP and a CalDav/CardDav resource, so dropping the dedicated Kolab resource in favor of this would simplify things. However, the tricky part is making that a smooth transition.

There’s also ongoing work to merge the Google calendar and contacts resources, providing a similar migration challenge, so we are looking for a general approach to replace outdated resources by creating the corresponding new ones and transitioning the configuration. This will require a re-sync of the data, but should be much more reliable than attempting to migrate the locally cached data.

Thanks!

Sprints are made possible thanks to KDE e.V. and its donors. And that’s something worth supporting as in-person meetings bring a substantial productivity and motivational boost. While we are currently constraint to doing all this virtually, this will change again eventually.