Generic maintenance work

[pvuorela]

Going forward there are bunch of details and work to be done. I'll list here some to get on the same page.

First, there's now slight of a problem for getting things merge into upstream. There used to be more colleagues at Jolla with merge rights to upstream Qt and we could review PRs from each other. For everyone else I can do the +2 but for my own contributions it's more of a problem. I've been occasionally bothering people with those, but there's always a bit of a barrier for doing that. Then again I've liked having the upstream elsewhere to have a possibility to clean up the delta here and with the bunch of reverts existing and all. Maybe could ask qt side if they could create some specific group for the repository and for starters having Damien approving rights there.

Then bunch of generic maintenance work to be done from the top of my head:

• Think we should kill the QtWidgets parts from messagingframework libraries. Here we don't build them. The QWidgets are lousy for modern touch UI. The code implements mostly just some account editors, but a proper mail app should do that by itself and its own style. Thus I don't think the related code really serves anyone doing a proper mail client. It's just noise.
• In the year 2025 it doesn't feel useful to build the project with QT_NO_SSL. The #ifdefs are just unnecessary noise. Could just require ssl.
• The code style needs cleaning up. Code review for example constantly having trailing spaces here and there, some of those fixed in sailfish patches (should remove that delta btw). I'd maybe run this through clang-format if I weren't that afraid of dealing with the patch conflicts.
• The file handling should follow XDG directories, ideally separating cache, data and config. Migration might have its problems but we can move files around in the packaging scripts. Elsewhere suppose the nicer the sooner it gets adjusted.
• The D-Bus API should be cleaned up not to serialize that much QDataStream inside D-Bus serialization. See e.g. around QMailStoreImplementationBase::ipcMessage(). This is having leftovers from the QCop IPC.
• Still too much patching here. Could consider more things pushed upstream directly or by some extension API.
• Plenty of items on internal Jolla bugzilla, but that's now mixing all the email related components and the app. If there's need for more work I can try going thru those for messagingframework specific items but maybe there's not yet that much need for more work :)

If needed, we can create separate issue items from these.

cc @gber @dcaliste

[gber]

Thanks for the summary, strongly agree with all of your points. Some minor points below:

* The file handling should follow XDG directories, ideally separating cache, data and config. Migration might have its problems but we can move files around in the packaging scripts. Elsewhere suppose the nicer the sooner it gets adjusted.

I already have a crude patch for that in the Debian package: https://salsa.debian.org/ubports-team/qmf/-/blob/master/debian/patches/1009-Prefer-Qt-standard-paths-for-application-data.patch?ref_type=heads

* The D-Bus API should be cleaned up not to serialize that much QDataStream inside D-Bus serialization.  See e.g. around QMailStoreImplementationBase::ipcMessage(). This is having leftovers from the QCop IPC.

As already discussed, it would be nice to have the Qt5 client to Qt6 server backwards compatibility, so distributions like Debian can package a single server.

CC @sunweaver

[dcaliste]

Thanks for the summary. Indeed, having yourself the only active member who can review with +2 limits your ability to propose patch yourself... Maybe could ask Robin Burchell his opnion, he commited on 2023, removing Symbian last pieces ? He may still look on the project sometimes and may have idea how and where to develop it further...

The file handling should follow XDG directories, ideally separating cache, data and config.

I fully agree, and the sooner the better. It may avoid the necessity to migrate for those who don't use it yet for production... One possibility could also be to switch to standard XDG directories in qmailnamespace.cpp but keep the env variable to change the directories, so the old behaviour can still be supported.

Still too much patching here. Could consider more things pushed upstream directly or by some extension API.

Indeed. Trying to reduce the numbers. Once the adjustments to solve #21 will be finished, I'm planning to resurrect https://codereview.qt-project.org/c/qt-labs/messagingframework/+/516422 but with a plugin approach, so libaccount is not a hard dependency.

[pvuorela]

I already have a crude patch for that in the Debian package: https://salsa.debian.org/ubports-team/qmf/-/blob/e9fd26edf9b30db690571b0335987c45ac260c81/debian/patches/1009-Prefer-Qt-standard-paths-for-application-data.patch

Btw that's missing "." from ".qmf" for backwards compatibility, but then adding it to the generic location which shouldn't have it.

But yea, something towards that direction. Though thinking if /mail/ subdirectory should be under cache. If moved, should check how it behaves if the directory gets removed.

For migration on sailfish we have this 'oneshot' thing which allows to execute scripts by, for example, each user after the package has been updated. We've used that when migrating files that got moved around and similar cases. Though if the old directory is detected, we could live with just using new path for new installations.

As already discussed, it would be nice to have the Qt5 client to Qt6 server backwards compatibility, so distributions like Debian can package a single server.

Indeed, also that. In theory the compatibility should be achievable by manually setting the datastream version, but nicer if we don't need to care about it at all.

Maybe could ask Robin Burchell his opnion, he commited on 2023, removing Symbian last pieces ? He may still look on the project sometimes and may have idea how and where to develop it further...

I suppose you might mean 9ba564c159 from 2013? Robin was working for Jolla back then.

I'm planning to resurrect https://codereview.qt-project.org/c/qt-labs/messagingframework/+/516422 but with a plugin approach, so libaccount is not a hard dependency.

That does sound nice!

[dcaliste]

I suppose you might mean 9ba564c159 from 2013? Robin was working for Jolla back then.

Ah yes. I was confused when someone added new reviewers in 2023 and the patch was moved up in Gerrit. I didn't look at it close enough at that time and thought Robin Burchell submitted it in 2023... Ok, forget about it then.