qxmpp-project / qxmpp

Cross-platform C++ XMPP client and server library
399 stars 198 forks source link

Support Qt4 to improve cross-platform compatibility #631

Open barracuda156 opened 1 month ago

barracuda156 commented 1 month ago

Given the statement in the README:

QXmpp strives to be as easy to use as possible.

Could support for Qt4 be added? There are platforms where Qt5 is broken completely, and many more where the bleeding-edge 5.15 does not build.

jbruechert commented 1 month ago

5.15 is not bleeding edge, most of the world has already moved on to Qt 6. Since QXmpp does not even support earlier versions of Qt 5 (for good reasons), I don't think adding support for Qt 4 is realistic.

Looks like the last version of Qt 4 was released in 2015, almost 10 years ago. It's probably even hard to still build it against modern crypto libraries, so everything connected to the internet should probably have migrated away already.

For little gain, it would make it impossible to use newer APIs and block the general modernization and keeping up with modern Qt.

From a somewhat outsiders perspective, I don't think this should be done.

barracuda156 commented 1 month ago

For little gain, it would make it impossible to use newer APIs and block the general modernization and keeping up with modern Qt.

I did not mean, of course, that it should be done at expense of newer systems. There are multiple projects which maintain compatibility with Qt4 and Qt5 both, and some also with Qt6. Functionally which cannot be supported in older Qt, can be excluded from respective code-paths.

For the record, the last version here with Qt4 support, 0.9.3, builds fine against the latest versions of all dependencies.

jbruechert commented 1 month ago

Let's take just one example: The connect syntax. Qt4 does not support the connect syntax used everywhere in this project by now. ifdefing all of this is not realistic. Using the old syntax takes the compile time checks from everyone, and will lead to a buggier library.

I still want to stress that Qt 4 should not be used any more anyway (I am aware you probably have technical reasons why you still use it), and should not be a concern for QXmpp.

barracuda156 commented 1 month ago

Qt4 does not support the connect syntax used everywhere in this project by now.

Well, this is not something I can evaluate. If it gonna require a non-trivial effort, it is arguably not worth.

I still want to stress that Qt 4 should not be used any more anyway (I am aware you probably have technical reasons why you still use it), and should not be a concern for QXmpp.

This is up to upstream, of course. I would say it is better to rephrase cross-platform part in a case older Qt are not supported though.

P. S. The reason to use Qt4 is simple: Qt5 does not build for my platform, and it is broken on a number of platforms, since, well, its upstream never bothered to write a properly cross-platform code from Qt5 onwards.

lnjX commented 1 month ago

P. S. The reason to use Qt4 is simple: Qt5 does not build for my platform, and it is broken on a number of platforms, since, well, its upstream never bothered to write a properly cross-platform code from Qt5 onwards.

What platform is that? And what application would want to use a modern QXmpp version with an unsupported Qt version, probably with security vulnerabilities?

Given the statement in the README:

QXmpp strives to be as easy to use as possible.

Easy-to-use and cross-platform doesn't mean that we support historical dependency versions or support every platform in the world.

Supporting Qt 4 is not realistic. We're using many Qt 5 features, also including crypto stuff like hmac and hashing algorithms like SHA2/SHA3, the used regular expressions are not compatible between Qt 4 and Qt 6, connect syntax and string handling. The question is rather when we can drop Qt 5 support to use stuff like QAnyStringView.

Everything of that could of course be solved in some way, but I doubt anyone would realistically need it. If you want to develop retro software, you can use QXmpp 0.9.3.