I had not been aware how far QtMobility was away from KCaldendar.
As far as I know, QtMobility has never been based or using KCalendarCore (formerly KCal). There was an official plugin based on mKCal (itself a child of KCal division) though, but the KCalendarCore API are not exposed, just used internally to the plugin. Actually, QtOrganizer (from QtMobility) and KCalendarCore (from KCal) are equivalent projects, allowing to represent in memory, calendar data (event, todos and journals), mostly conforming to the iCal RFC2554.
Besides, QtMobility has been abandonned. It didn’t reach Qt5 era and stayed with Qt4 APIs. With KDateTime in QtOrganizer for instance because at that time Qt was not handling well time zones in QDateTime.
The elements of QtMobility have been separated into smaller pieces. For instance QtFeedback is now a standalone Qt module. QtContacts and QtOrganizer (with some other modules) have been put into a new module named QtPim. And QtPim has been upgraded up to Qt6.
The engine plugin for QtOrganizer based on mKCal from QtMobility has also been abandonned with QtMobility and didn’t go into QtPim (there is no QtOrganizer engine in QtPim besides the memory one). The APIs in mKCal and in QtOrganizer have changed much, that’s why I decided to rewrite a plugin from scratch instead of adapting the existing one from QtMobility and the Qt4 era.
the QtMobility sqlite backend could ‘merge’ towards mKCal ?
What do you mean ? The old mKCal plugin from QtMobility sources can be upgraded to adjust for API changes, but the solution I propose, was to rewrite it.