Qt 6 compatibility

[pbek]

Lots of deprecation warnings will be fixed to further advance the Qt 6 compatibility of QOwnNotes.

[pbek]

19.10.2

• fixed several deprecation warnings to further advance the Qt 6 compatibility of QOwnNotes

[Waqar144]

I was compiling the code yesterday and was wondering why there are so many deprecation warnings left standing.

[pbek]

Why were you wondering?

[pbek]

19.10.3

• fixed several more deprecation warnings to further advance the Qt 6 compatibility of QOwnNotes in the future

[Waqar144]

Oh, just cause I thought I wouldn't encounter that. I was going to make an issue about this till I saw this Issue.

[pbek]

Oh, just cause I thought I wouldn't encounter that. I was going to make an issue about this till I saw this Issue.

I didn't wrote that the effort to make the App work with old Qt versions as low as Qt 5.3 and have no deprecation warnings with Qt 5.13.1 was already done. A lot of stuff in the App plus all the library needed and needs to be rewritten, this takes time. 😄

[Waqar144]

I understand. :+1: I will try to help :smile:

[pbek]

Thank you 😃. I think all is done but the botan library, but I wonder if I it isn't better to make an effort to get botan 2 running (see #1263), so if you want to help #1263 is a good place to start. 😁

[Waqar144]

I will take a look at it and definitely try to make an effort :eyeglasses:

[pbek]

19.10.4

• fixed deprecation warnings of Botan library for encrypting notes

[pbek]

https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/Debian_8.0/i586

@Waqar144, seems like some things got broken in older versions of Qt 😉

[  139s] helpers/codetohtmlconverter.cpp: In member function 'QString CodeToHtmlConverter::xmlHighlighter(StringView) const':
[  139s] helpers/codetohtmlconverter.cpp:521:77: error: no matching function for call to 'QRegularExpression::globalMatch(const QStringRef&)'
[  139s]                  QRegularExpressionMatchIterator matchIt = re.globalMatch(tag);
[  139s]                                                                              ^
[  139s] helpers/codetohtmlconverter.cpp:521:77: note: candidate is:
[  139s] In file included from ../../../include/i386-linux-gnu/qt5/QtCore/QRegularExpression:1:0,
[  139s]                  from helpers/codetohtmlconverter.cpp:4:
[  139s] ../../../include/i386-linux-gnu/qt5/QtCore/qregularexpression.h:120:37: note: QRegularExpressionMatchIterator QRegularExpression::globalMatch(const QString&, int, QRegularExpression::MatchType, QRegularExpression::MatchOptions) const
[  139s]      QRegularExpressionMatchIterator globalMatch(const QString &subject,
[  139s]                                      ^
[  139s] ../../../include/i386-linux-gnu/qt5/QtCore/qregularexpression.h:120:37: note:   no known conversion for argument 1 from 'const QStringRef' to 'const QString&'

[Waqar144]

Things that can be done for Qt6 right now

• [x] Move away from QStringRef for Qt6. Either use QString or QStringView.
• [x] Move away from QRegExp to QRegularExpression. Not all older Qt API supports it properly so this will probably need a lot #ifdefs . Some third party libraries use it extensively and most of them are not being actively maintained so it will be upto us to fix this I guess.
• [ ] Move away from qmake. It may get removed? and cmake seems to be the future
• [x] QWebSockets is not available yet, It is unclear when it will be available. That is necessary for browser extensions I think
• [ ] No explicit x11extras modules for Qt6. QHotKey depends on this
• [ ] No xmlpatterns in Qt6. This is used in importing evernote notes and to a small extent in OwnCloud code. Not clear what to do yet
  • Bring a third party library for this?? ALL third party xmlpattern libraries are huge.
  • Write a custom parser for just what we need and skip a dependency?
• [x] QTextCodec is gone. We need to work around this as well.
• [x] Fix all deprecation warnings, they are errors in Qt6

[pbek]

Quite the list!

[Waqar144]

Let's hope this is all ;p

We can start slow. Do the things that are possible for now, and wait for the rest.

[pbek]

Thank you for your research and the ongoing fixes!

[pbek]

@Waqar144, some builds are still failing after your last PR, e.g. https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/openSUSE_13.2/x86_64

[pbek]

@Waqar144, even the Fedora 33 build seems to fail: https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/Fedora_33/x86_64

[pbek]

@Waqar144, Fedora 33 is still broken after your last PR: https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/Fedora_33/x86_64

[pbek]

Still broken, @Waqar144 https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/Fedora_33/x86_64

[pbek]

@Waqar144, Fedora 33 really behaves strange. It should use Qt 5.15.2. Maybe the OBS builder uses something earlier, like 5.15.1 or 5.15.0?

Do you use the new Qt 5.15.2 methods from https://doc.qt.io/qt-5/qstringview.html or can we start with 5.15.0, instead of 5.15.2 in helpers/codetohtmlconverter.h:13?

[pbek]

Finally the Fedora 33 build succeeded, thank you @Waqar144. https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/Fedora_33/x86_64

[Waqar144]

I was wondering about it, thanks for telling me.

QWebSockets is coming with Qt 6.2, that is good news. Now we just need to port away from QRegExp.

For xmlpatterns, can we do it manually somehow? I don't know much about them or how they are used but if it can be done manually that will be much better as dragging in a huge dependency will be a maintenance pain.

On Tue, May 4, 2021 at 10:20 PM Patrizio Bekerle @.***> wrote:

Finally the Fedora 33 build succeeded, thank you @Waqar144. https://build.opensuse.org/package/live_build_log/home:pbek:QOwnNotes/desktop/Fedora_33/x86_64

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[pbek]

For xmlpatterns, can we do it manually somehow?

you mean migrate away from it?

[Waqar144]

This issue is mostly done. Two things remaining:

• QHotKey needs to be synced with upstream which has implemented Qt6 support
• Qt Xml Patterns code paths don't work, but they are very few so most of the things work nicely

[pbek]

QHotKey needs to be synced with upstream which has implemented Qt6 support

Done

[pbek]

Too bad Qt 6.3 seems to be still broken, not even qmake is found (I can't see any hint that they dropped qmake).

https://github.com/pbek/QOwnNotes/runs/5011376807?check_suite_focus=true

[Waqar144]

Specified Qt version is unknown: 6.3.0. Some of specified modules are unknown.

6.3 is not released yet, so we can't really test against it except if we build the whole Qt ourselves of course.

[Waqar144]

Btw, I have been having an idea, not sure how good it is. We can try to build our own libc (musl) and link to it statically. That may make a lot of glibc backward compatibility issues disappear.

Also, I think maybe we should drop the aspell dependency because we only support it on Linux, and it's pretty much the only external dependency we have other than Qt.

[pbek]

6.3 is not released yet, so we can't really test against it except if we build the whole Qt ourselves of course.

Ah, I thought it was ok because it was on https://download.qt.io/online/qtsdkrepository/linux_x64/desktop/

Btw, I have been having an idea, not sure how good it is. We can try to build our own libc (musl) and link to it statically. That may make a lot of glibc backward compatibility issues disappear.

Will that also work on Windows and macOS, or don't we need to make them work there? Will it break our build systems?

Also, I think maybe we should drop the aspell dependency because we only support it on Linux, and it's pretty much the only external dependency we have other than Qt.

What will then be used? Hunspell?

[Waqar144]

Yes, just hunspell.

Ah, I thought it was ok because it was on https://download.qt.io/online/qtsdkrepository/linux_x64/desktop/

Indeed, maybe the aqt only supports released versions? I wonder why they don't keep older versions there.

Will that also work on Windows and macOS, or don't we need to make them work there? Will it break our build systems?

For windows/mac, we don't need to change anything as such issues don't happen there (we don't have to compile for every windows version, we just do it for one, right? (not sure about mac)). Linux is a different story, for every distro...

I haven't done it every, and not even sure how one would do it using qmake atm. But if it works on github CI, it should work everywhere else too. But its all theoretical at this point, and would take some work if we try to go this way.