Dear QtPim lovers, QtPim is back. It compiles, it's connected to COIN, all tests pass. There is some more work to do, e.g. migrating string based connections to PMF. I have changed the tag from v5.0.0 to v6.12.0-beta1. Thanks to all my patient reviewers.
Please note, that QtPim is not an official Qt module. It lives from the love it gets from our wonderful community. Before I disengage gracefully and move on to other things in my free time, I'd like to repeat one thought: Contacts and calendar items are great. In the world of messengers: A message abstraction would be a great addition. Message plugins (starting with email) could handle multiple messenger platforms and enable Qt applications to communicate both internally with their own chat container, as well as to the outside world. Just a thought. Cheers Axel Confidential ________________________________ From: Development <[email protected]> on behalf of Axel Spoerl via Development <[email protected]> Sent: Friday, 5 June 2026 14:58 To: [email protected] <[email protected]> Subject: Re: [Development] Reviving QtPIM Hi, Indeed I made one huge commit that makes it compile, even though I prefer atomic normally. IMHO that’s an exception, because smaller commits would have to merge in the right order and couldn’t be reverted individually. QtPim compiles against the sha1s of qtbase and qtdeclarative listed in dependencies.yaml. That’s essentially Qt 6.12. The problem now is that our CI doesn’t know about QtPim. We need to fix that first, before anything can merge. > On 2 Jun 2026, at 15:16, Adriaan de Groot <[email protected]> wrote: > > On Thursday, 28 May 2026 08:00:27 CEST Axel Spoerl via Development wrote: >> 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. > > I see you did a complete Qt-style conversion in one commit. Thank you. I'll > withdraw my artisanal / partial conversions from Gerrit, since they are less > complete than yours. > > I couldn't get your CMake conversion to work, though, with released Qt 6.10 or > 6.11 open source versions (as packaged on FreeBSD). There's CMake machinery > being used in your patch that doesn't exist in those versions. So downstream > on KDE Invent I took your patch and then chopped at it so it does build with > older CMake machinery. > > Downstream is at > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Finvent.kde.org%2Fadridg%2Fqtpim%2F-%2Ftree%2Fwork%2Fqt6%2Frelease&data=05%7C02%7C%7Cecf72d2cd2fe4b2c485408dec3027b3c%7C20d0b167794d448a9d01aaeccc1124ac%7C0%7C0%7C639162612591179296%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8SCcPq70wyIOf%2B0SyALHFtMR7HEkHwzFuTp%2BTOxS%2FaI%3D&reserved=0?<https://invent.kde.org/adridg/qtpim/-/tree/work/qt6/release> > ref_type=heads with the intention to package it for some distro's from there, > if only so that there is a "QtPIM for Qt6" out there already as a crutch to > help port things that depend on Qt5PIM to Qt6. > > But what next? Supposing this CMake conversion gets merged (and IMO it > should), then it falls apart on the build step. There are many downstream > "make it compile" patches -- lots of them submitted upstream in Gerrit but I'm > afraid I'm making a mess there -- that are needed together with the CMake > conversion in order to get it to pass CI. > > I'll +1 your conversion now. > > [ade] > <signature.asc> -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
