Future of vsgQt, looking for community feedback

[robertosfield]

Hi All,

This week I've been reviewing a couple of submissions from @asafran, that addressed Qt6 warnings and Wayland support. These PR's prompted me to do some refactoring to address the issues that these PRs raised and do some refactoring to simplify and make vsgQt a little more flexible.

The Qt6 warnings are now addressed and merged with vsgQt master. The Wayland support I've tackled as part of a wider refactor and simplification that needs testing across platforms as I'm only able to test with Kubuntu right now, so I'd appreciate testing under Linux with Wayland, Windows and macOS before I merge with vsgQt master. The changes are checked into branch:

https://github.com/vsg-dev/vsgQt/tree/RefactorInstanceExtensionSurfaceName

In theory these changes should also open the door to supporting Android and iOS, and perhaps longer term QNX and other combinations. To simplify the code I've removed the old code for enabling use of native vsg::Surface implementations, doing this means we rely entirely on Qt to create the vkSurface, unfortunately this also means Qt has to have Vulkan support, so now Qt 5.10 is now the minimum supported version.

One of the changes I haven't carried over from Andrei's changes were to vsgQt/CMakeLists.txt implemented Qt detection, the changes are:

$ git diff master CMakeLists.txt
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 0b56f79..85e2fe1 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -15,8 +15,6 @@ set(VSGQT_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}" CACHE INTERNAL "Root binary d
 set(CMAKE_CXX_STANDARD 17)
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
-set(QT_PACKAGE_NAME Qt5 CACHE STRING "Set Qt package name, i.e. Qt5 or Qt6.")
-
 find_package(vsg 1.0.0)
 
 vsg_setup_dir_vars()
@@ -24,7 +22,8 @@ vsg_setup_build_vars()
 
 
 find_package(vsgXchange) # only used by exanples
-find_package(${QT_PACKAGE_NAME} COMPONENTS Widgets REQUIRED)
+find_package(QT NAMES Qt6 Qt5 REQUIRED COMPONENTS Core)
+find_package(Qt${QT_VERSION_MAJOR} COMPONENTS Widgets REQUIRED)
 
 vsg_add_target_clang_format(
     FILES

I haven't merged this as I would rather users explicitly select which Qt version to use and it's not clear to me how this might be achieved with the above changes. However, it does raise a wider issue, how should users select which Qt version they wish to build vsgQt for, and what happens when users want to have both Qt5 and Qt6 versions of vsgQt on their system for different projects. If 3rd party package maintainers want to distribute binaries for vsgQt they will also face this issue.

How might be navigate this? Have a vsgQt5 and vsgQt6 libraries built side by side? Do something crazy like make vsgQt a header only so there's no lib at all, and have the Qt version determined at compile time by the application using it?

Longer term I'd like to refactor vsgQt to handling multiple windows with them sharing a single Viewer rather than the ViewerWindow cludge that we currently have. I don't know how best to do this as Qt has control over the when the windows get redrawn which is different to how the VSG native windowing and viewer are designed to be used where the viewer tells the windows to redraw on each new frame.

I'm open to suggestions as I'm no Qt expert, I'm just learning Qt which trying to figure out how to make vsgQt work satisfactorily.

Right now I'd also appreciate testing of the RefactorInstanceExtensionSurfaceName branch of vsgQt. If things look to be working correctly under Windows, macOS and Linux+Wayland I'll go ahead and merge with VSG master.

[asafran]

Hi All,

I will tell you my solution to the Qt backward compatibility problem, based on the experience of compiling vsgQt on Qt6.
Usually, Qt developers use pre-compiled binaries from the official website, which you can download using an online installer. Files are uploaded to the user's specified folder, e.g. in Linux default location is the user's home folder, or to another location on the system, but not to the system libraries directory. To compile with a specific version of qt, the developer must specify the installation location of Qt as CMake prefix variable, in which case it is necessary to determine the version of qt automatically, otherwise CMake will try to search for Qt in the system directories, and not in prefix path. So, to compile vsgQt with Qt6, I passed to CMake -DCMAKE_PREFIX_PATH=*instalation_dir*/Qt/6.2.2/gcc_64/lib/cmake/ -DQT_PACKAGE_NAME=Qt6 . If I don't pass -DATA_PACKAGE_NAME=Qt6, CMake will try to find Qt5, not Qt6. Internally, Qt Creator uses CMAKE_PREFIX variables to switch between build kits and Qt versions. My approach is that we need automatic detection of the Qt version, and the user will choose the qt version via CMake prefix. This approach is recommended by the Qt documentation.

For find_package to be successful, CMake must find the Qt installation in one of the following ways:
Set your CMAKE_PREFIX_PATH environment variable to the Qt 5 installation prefix. This is the recommended way.
Set the Qt5_DIR in the CMake cache to the location of the Qt5Config.cmake file.

When automatically determining the Qt version, we can simply set the CMAKE_PREFIX_PATH variable to select the Qt version, otherwise CMake will search for qt in the system directories and it is not known which version will be selected, therefore it is always recommended to specify exactly the path to the Qt installation, and not the package name.

Qt 5.15 also introduced versionless CMake targets. If we raise the minimum version of Qt to 5.15, it will make the task easier, but there may be difficulties with older versions of Linux distributions.

The decision is up to the community!

[robertosfield]

I presently use CMAKE_PREFIX_PATH to install all my personally built libraries + programs, so curl/assimp etc. through to VSG etc. Would like be workable with your/Qt community suggested use of CMAKE_PREFIX_PATH?

[robertosfield]

Oh, could you also provide feedback on my queries about whether we should create vsgQt5 + vsgQt6 libraries or header lib?

I'm looking for solutions for all usage combinations.

On the Qt version, I'd much rather keep compatibility with older version as long as it doesn't compromise the usability and maintainability of the code.

[asafran]

I presently use CMAKE_PREFIX_PATH to install all my personally built libraries + programs, so curl/assimp etc. through to VSG etc. Would like be workable with your/Qt community suggested use of CMAKE_PREFIX_PATH?

You can also use the _DIR CMake cache variable to explicitly specify the path to Qt or other libraries. Most Qt developers use Qt Creator, which handles Qt prefix transparently.

However, it does raise a wider issue, how should users select which Qt version they wish to build vsgQt for, and what happens when users want to have both Qt5 and Qt6 versions of vsgQt on their system for different projects. If 3rd party package maintainers want to distribute binaries for vsgQt they will also face this issue.

I don't see a problem in compiling vsgQt with different CMAKE_PREFIX_PATH/Qt6_DIR/Qt5_DIR and CMAKE_INSTALL_PREFIX. Further packaging problem can be solved by the built-in tools of the packaging system. We can just write a script that will handle this.

Header library is also a good solution, but the question is how much the vsgQt functionality will grow in the future, and how it will affect the readability of code in this format. At the moment, I think this is the most optimal solution, but it requires significant changes and testing.

On the Qt version, I'd much rather keep compatibility with older version as long as it doesn't compromise the usability and maintainability of the code.

It will not be difficult to provide support for older versions of Qt5, since this is solved only by an additional CMake variable

[robertosfield]

When you say the current solution, do you mean vsgQt master or your PR?

I don't have grand plans for vsgQt, just to make sure it works easily across platforms and VSG/Qt versions and to better support the multiple window usage case. The later is the biggest new functionality change, however, I'd hope it won't require too much more code.

Current vsgQt library just has 705 lines of code:

$ wc include/vsgQt/.h src/vsgQt/.cpp
42 96 886 include/vsgQt/Export.h
35 216 1660 include/vsgQt/KeyboardMap.h
83 396 3735 include/vsgQt/ViewerWindow.h
242 940 9761 src/vsgQt/KeyboardMap.cpp
303 795 9387 src/vsgQt/ViewerWindow.cpp
705 2443 25429 total

Even with the better multiple window I would have thought this would stay less than 1000 lines of code. This would still be pretty modest even for a pure header based case, so I don't envisage particular maintenance burden on going this route.

I may create a branch to test out the header only path to see if it hangs together nicely or not, it might just make things cumbersome and out of step with the rest of the VSG exosystem.

[ghost]

There may be a limited demand for vsgQt. The Qt Company has shifted towards licensing new code additions under the GPL3+ license instead of the LGPL. This change require's individuals who do not wish to license their projects under the GPL to purchase a subscription. This approach is similar to the one taken by Oracle with Java and was a contributing factor in the development of Kotlin by Google. It's also why we don't see very many KDE/Qt forward Linux distributions anymore. Everyone is moving to permissive licenses.

Many people are interested in Wayland and KMS/DRM support, and luckily, projects such as SDL, GLFW, and SFML https://github.com/SFML/SFML have covered this aspect well. If you're curious, I actually wrote an example 11 years ago demonstrating how easy it is to integrate SFML and OSG3. You can find it here: https://gist.github.com/zester/2402691.

Why not just provide a working Qt5/Qt6 example.

option(ENABLE_QT5 "Enable Qt5 support" ON)
option(ENABLE_QT6 "Enable Qt6 support" OFF)

if(ENABLE_QT5)
    find_package(Qt5 COMPONENTS Widgets REQUIRED)
    add_definitions(-DUSE_QT5)
endif()

if(ENABLE_QT6)
    find_package(Qt6 COMPONENTS Widgets REQUIRED)
    add_definitions(-DUSE_QT6)
endif()

if(ENABLE_QT5)
    target_link_libraries(MyProject PRIVATE Qt5::Widgets)
endif()

if(ENABLE_QT6)
    target_link_libraries(MyProject PRIVATE Qt6::Widgets)
endif()

[robertosfield]

I see vsgQt as useful to existing Qt users, including clients of mine, it's existence doesn't preclude integration with other libraries.

At a personal level I am not impressed by Qt, the core VSG implements it's own windowing which is far better suited for real-time graphics but I can't dictate what members of the community find useful for their own applications. Improving vsgQt helps the life of those stuck using Qt for their applications.

[sbrkopac]

Personally, I use Qt when I need things like an extended toolbar, different layouts with different widgets such as the QDirView.

[reedev]

Hi,
Fwiw, I just use the current version of the vsgQt in a very pragmatic and simple way. Old way?

For any non-standard version (previously from a download or a self-built) I just
export QTDIR=base directory
Add $QTDIR/bin to PATH
Add $QTDIR/lib to LD_LIBRARY_PATH

Works like a charm for many years now.

In general I would be interested in a replacement for Qt when it comes to creating menus, widgets, layouts which are good looking, because of the changes in licensing.

Cheers, have a great day

[rainergericke]

While vsgQT works on Linux and Windows I see no possibility to build it on the Mac. There is no QtVulkan in the installed binaries, it cannot be configured from the qt sources as well. Is there any Mac expert with better experience?

[rainergericke]

Hi Oleg, thanks for the info. I tried to build vsgQtViewer with qt-6.5 today. I wasn't successful yet, since a header file is missing:


What did I do wrong?

[olegded]

I believe you will see this error if your Qt version doesn't have/was compiled without Vulkan support, which is the case for the Qt versions you will get via download or brew (at least it was like this as I tried it). I cannot really remember exact configure steps (and if there are any Vulkan specific options or not), my Qt's CMake configuration includes following defs for the Vulkan support, pointing to the MoltenVK installation:

[reedev]

While vsgQT works on Linux and Windows I see no possibility to build it on the Mac. There is no QtVulkan in the installed binaries, it cannot be configured from the qt sources as well. Is there any Mac expert with better experience?

From my experience of building Qt from source code on Linux, I can suggest that vulkan needs to be found before Qt can be built with Vulkan support. When you use configure when building Qt, you can see if Vulkan is found or not. When it's found, Qt will be built with Vulkan support and then vsgQt is working too.

I cannot tell if this is the same on Mac too but I guess there is a good chance

[rainergericke]

Thank you for setting me on the right trail!

Step 1 Generate a qt 6.5.0 distribution with Vulkan support on the Mac
On my Mac the Vulkan SDK is in ${HOME}/VulkanSDK/1.3.243.0.
To configure Qt on macOS two settings are important:
configure -I ${HOME}/VulkanSDK/1.3.243.0/macOS/install -L ${HOME}/VulkanSDK/1.3.243.0/macOS/lib ... blah ...

After building and installing Qt-6.5.0 with Vulkan enabled:
Step 2 Build vsgQt
Well this does not work out of the box. There is one faulty line:
traits->nativeWindow = reinterpret_cast<NSView*>(winId());
A c++ type cast with a obj-c type in a c++ compile unit is not allowed/possible.
Some kind of masquerade helps yet. Ilya Kryukov shows a solution in his repository https://github.com/ikryukov/QtVulkan.git
After applying the necessary changes I am able to build vsgQt on the Mac.

[reedev]

Nice job!