[Development] Reviving QtPIM

[Axel Spoerl]

It's been a while since I was a user of QtPIM, and I found it quite solid  back in the day.
Can't promise how much time I can make for this, but I am definitively down to review a few patches.

A good first step would be to migrate the submodule to CMake.

Confidential
________________________________
From: Development <development-bounces at qt-project.org> on behalf of Chris Adams <chris.adams at qinetic.com.au>
Sent: Thursday, 28 May 2026 07:47
To: Adriaan de Groot <groot at kde.org>
Cc: development at qt-project.org <development at qt-project.org>
Subject: Re: [Development] Reviving QtPIM

Sounds great - thanks very much for stepping up to do that.
Please ping me if I don't respond to a gerrit review in a timely fashion!
I definitely will review patches on gerrit associated with the module.

Best regards,
Chris.


On Tue, May 26, 2026 at 11:16 PM Adriaan de Groot <groot at kde.org<mailto:groot at kde.org>> wrote:
On Tuesday, 19 May 2026 17:39:14 CEST Vladimir Minenko via Development wrote:
> 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.

OK, that is a fairly clear "this isn't used by customers" kind of answer. I
can't speculate about why there would be problems compiling QtPIM -- unless
-Wall -Werror is in play, because the code has not been updating for newer
compilers with picky defaults (or, for instance, downstream consumers
switching to newer C++ standards).

> 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. ... 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.

That is clear enough. Here's what I'll do:

I will continue throwing things about deprecations at Gerrit (e.g. missing
includes to make it compile at all, post-Qt5-deprecations, ...) when I have
them worked out. There's a dozen or more items out there already, e.g. Qt::UTC
becoming QTimeZone::UTC is one uninteresting bunch of commits.

Simultaneously, I'll do a CMake port and throw that at Gerrit as well. There
might be C++ code changes in that branch too -- I don't know if QtPIM can even
compile as-is against any reasonably-recent Qt release.

*Downstream*, in KDE Invent (or whatever) I'll merge these various kinds of
fixes into something I can tag and package for Linux distro's who need QtPIM
data structures and data-handling, who would like to leave Qt5 behind.

[ade]--
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20260528/85f09c5c/attachment-0001.htm>