Qt6 support

[equalsraf]

Tracking issues for supporting builds against Qt6 - I was able to build against Qt6 after some changes, but I could not test, here is the list of issues

• [x] CMake can support mixed Qt5/6 builds https://doc-snapshots.qt.io/qt6-dev/cmake-qt5-and-qt6-compatibility.html
• [x] windeployqt is failing in qt6 windows
• [ ] static builds (windows) are failing for qt6 - we also lack CI for this option

APIs removed in Qt6, need to check if these can be replaced (current minimal version is 5.8):

• [x] QLayout::setMargin
• [x] QStringRef -> QStringView
• [x] QStringView.toInt()/toFloat() does not exist in Qt5
• [x] Qt::MidButton
• [ ] Qt::ImMicroFocus
• [x] QPalette::Background/Foreground
• [x] QDesktopWidget -> QScreen
• [ ] QFont::ForceIntegerMetrics
• [x] QProcess/QTcpSocket/QLocalSocket::error(...errortype) signal is not available in qt6
• [ ] qRegisterMetaTypeStreamOperators was removed from Qt6, need to test QSettings serialization (see neovimconnector.cpp)

Changes:

• [x] QTextCodec is now part of the Core5Compat module and this module is not part of the default install (windows?) - just remove it - we always hardcode utf8 anyway!
• [x] dependency on QtSvg moves to QtSvgWidgets - and consumers of these dlls e.g. https://github.com/neovim/neovim/blob/667e3bfb6e9dcd3287f2082edd83068d5428f3af/src/nvim/CMakeLists.txt#L507-L568

Other issues

• [x] some includes had to be adjusted
• [x] const operator needed adjustment
• [x] QList and {} fail to build tests, there is also an error with const in the related for loops
• [ ] new deprecation warnings
• [ ] test failure in the shell widget, related to the font (invalid font weight)

[jgehrig]

dependency on QtSvg moves to QtSvgWidgets

I just thought of this... We should watch for DLL name changes on Windows.

Neovim hard-codes DLLs for copy: https://github.com/neovim/neovim/blob/667e3bfb6e9dcd3287f2082edd83068d5428f3af/src/nvim/CMakeLists.txt#L507-L568

https://github.com/neovim/neovim/issues/12928

The response from Neovim will probably be to remove the bundled neovim-qt. They almost did that last time :/

[equalsraf]

I just thought of this... We should watch for DLL name changes on Windows.

I was not planning on turning on Qt6 as default any time soon, just to introduce support to build with Qt6. Defaulting to Qt5.

The response from Neovim will probably be to remove the bundled neovim-qt. They almost did that last time :/

Well no one likes bundling dependencies :D. And as the TUI in windows becomes better it also makes sense (for neovim) to leave it to the user to pick the GUI and shed the download size.

The only thing that can be done on this end is to make it easier for users to install neovim-qt.

I dont remember why the build recipe was copying files one by one, It should be enough to unpack the zip. The exact same problem could happen with changes to the plugin

https://github.com/neovim/neovim/blob/1186f7dd96b054d6a653685089fc845a8f5d2f27/CMakeLists.txt#L548

It is probably worth investing time in simplifying that recipe inside neovim.

[jgehrig]

All sounds good :+1:

Well no one likes bundling dependencies :D

Yes, I don't blame them... I think re-directing neovim-qt bugs is a source of frustration for the Neovim devs.

Even with all of the improvement, the terminal emulator on Windows is poor (IMO). I feel there is value in providing a bundled GUI that "works out of the box". That's what Vim does on Windows with gVim. I suspect Neovim will loose new users without a similar option... Ohh well!

For Linux/MacOS, I completely agree: let the user choose. Installation is easier.

It is probably worth investing time in simplifying that recipe inside neovim.

I tried, but couldn't come up with anything clever... My knowledge of CMake isn't the greatest.

The problem I ran into was output from all of the third-party packages were dumped into a flat directory. I couldn't separate neovim-qt output from the other packages.

Extracting a ZIP would be simple, but might cause issues if the compiler (MSVC, MinGW) and architecture (32-bit vs 64-bit) don't align. Not sure?

[equalsraf]

Extracting a ZIP would be simple, but might cause issues if the compiler (MSVC, MinGW) and architecture (32-bit vs 64-bit) don't align. Not sure?

I dont think alignment between neovim and neovim-qt is a problem. The only interaction between the two is by calling the process i.e. neovim can be build with mingw and neovim-qt with visual studio and it should be fine. The only problem is if we place a 64 bit binary in a 32 bit system.

The problem I ran into was output from all of the third-party packages were dumped into a flat directory. I couldn't separate neovim-qt output from the other packages.

That definitely makes sense for buildtime or dependencies (curl, win32yank) or runtime dependencies used in the tests. I need to have a look into third-party again, but it would probably have to skip the unzip in the third-party build stage - only later when neovim gets installed it would grab the zip file and install.