> 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 > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.qt-project.org/listinfo/development >> -- >> Development mailing list >> [email protected] >> https://lists.qt-project.org/listinfo/development > > -- > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
