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]
signature.asc
Description: This is a digitally signed message part.
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
