[Development] Reviving QtPIM

Vladimir Minenko vladimir.minenko at qt.io
Tue May 19 17:39:14 CEST 2026


> I ping’ed our product folks in the Qt company to see if we have seen any customer-level interest in this recently.

As one of those folks, I looked up Qt Support cases. The last one for QtPIM was from 2019, and it was only about problems to just compile it. I also cannot recall any mentioning of QtPIM or related functionality on any other channels to Qt users and customers. Yet, I can list a notable number of other APIs which were requested multiple times, but they are still not in Qt. One example which I quickly recall is USB support.

In general, I have my serious doubts if QtPIM fits into Qt as it is today, in 2026, or should be tomorrow, if I may add. QtPIM comes from the Qtopia and Qt Mobility times (~2009-2010). Many things fundamentally changed since then. Not starting a philosophical discussion about platforms here, I wish today’s Qt would keep being focused on functionality at its current layer in the overall API stack. There is still a lot of work to do. Any PIM APIs sit on a higher API level and are much more application-specific than almost any other API in Qt today.

Greetings! 

--
Vladimir

> On 15. May 2026, at 10:07, Volker Hilsheimer via Development <development at qt-project.org> wrote:
> 
> Hi all,
> 
> I ping’ed our product folks in the Qt company to see if we have seen any customer-level interest in this recently.
> 
> FWIW, we just merged HarmonyOS platform support into dev for Qt 6.12, which is primarily a mobile platform. Which might make a cross-platform API to interface with system services for PIM more relevant again.
> 
> Releasing it as a supported piece of Qt is not on the immediate horizon, at any rate. But for the time being, I hope that continuing to use codereview.qt-project.org as the official upstream doesn’t make it harder per se to package things up for the relevant target platforms. We don’t test/package the rest of Qt for SailfishOS or Lomiri specifically today either.
> 
> Maybe a good topic to discuss at Qt Contributors Summit _hint hint nudge nudge_
> 
> https://wiki.qt.io/Qt_Contributors_Summit_2026
> 
> 
> Volker
> 
> 
>> On 14 May 2026, at 17:11, Chris Adams <chris.adams at qinetic.com.au> wrote:
>> 
>> Hi Adriaan,
>> 
>> I'm happy to review patches.  I cannot speak for Pekka Vuorela, but he may or may not also be willing to review things.
>> But I know nothing about releasing, nor had I intended to do any release-specific work on QtPIM in the future.
>> I'm open to being persuaded, especially if it doesn't take too much effort (I'm just entirely ignorant of the process / requirements).
>> 
>> QtPIM parts are (or at least, were) used a bit in Sailfish OS, so I don't think Lomiri is the only user.
>> 
>> Best regards,
>> Chris.
>> 
>> 
>> 
>> 
>> On Fri, May 15, 2026 at 12:32 AM Adriaan de Groot <groot at kde.org> wrote:
>> QtPIM development stopped in 2020 -- Luca Weiss bumped the module version to 
>> 6.0.0, but it was never, AFAIK, part of any Qt 6 release. It also never was 
>> updated with CMake as a build-system.
>> 
>> There are consumers of QtPIM, though. Lomiri, a Free Software convergent 
>> software stack (think tablets, phones, and desktop), uses it. There's an effort 
>> going on to update that to Qt 6, which would include QtPIM.
>> 
>> I have dealt with the build-system and porting to Qt6, such that it builds and 
>> passes autotests. I haven't dealt with the QML, yet -- I presume that will 
>> need more work as the language itself changed a bit. That work happened on KDE 
>> Invent, because (a) there's a mirror there due to the KDE Free Qt Foundation 
>> work and KDE Free Qt Patch collection work -- that was relevant at the tail 
>> end of the Qt5 era -- and (b) that GitLab instance supports personal work-
>> branches even in mirrored repositories. The mirror is, however, supposed to 
>> just mirror upstream.
>> 
>> But it leaves me (and Lomiri) in a weird situation: there's work being done, 
>> and it is sort-of-upstreamable, but I can't point at an upstream and say "it 
>> goes there" because Qt hasn't done a release of this in years.
>> 
>> So what should I do here? I can throw things at Gerrit, but that only makes 
>> sense if this ends up in a releasable state eventually (I'd be personally 
>> satisfied it it was releaseable on common Free Software platforms, and don't 
>> care about esoteric ones ..). It could be hard-forked with the same name and a 
>> different "upstream", or renamed. I'm open to suggestions.
>> 
>> [ade]-- 
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
>> -- 
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
> 
> -- 
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development



More information about the Development mailing list