-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qt 6 support #52
Comments
Can you for now fork and let us access the porting in the meantime? I have been looking at the CMake code and is quite complex but, as you say, changes in Qt are quite small. So I would prefer to have a single solution splitting/redoing CMakeLists.txt files based on Qt version and a few ifdef (#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0) and so on..) in C++ code. Thanks, David |
I put the minimal Qt 6 changes in a No If the plan is to merge the CMake changes to support Qt 5 and 6 I think the logic has to respect |
Thanks for the fork @DeadParrot and, yes, you are right, better use -DDESIRED_QT_VERSION |
Hello @DeadParrot , I just looked at your modifications here : DeadParrot@c4d48d1 I wanted to tell you that I did essentially the same thing on my side at the beginning of October 2021. For the file src/osgQOpenGL/OSGRenderer.cpp, indeed most of the changes are compatible with Qt5 at the exception of one line, line 356 : m_osgWinEmb->getEventQueue()->mouseMotion(event->position().x() * m_windowScale, event->position().y() * m_windowScale); ---> Indeed with Qt5.12.11 we need to keep the 'old' one : m_osgWinEmb->getEventQueue()->mouseMotion(event->x() * m_windowScale, event->y() * m_windowScale); PS: as you may have read, I tested with Qt5.12.11 and I guess you didn't have this problem because you probably tested with Qt5.15.x (which introduces most things for Qt6) ? But it is very good news that we have arrived at much the same thing. :-)) |
Hi @mtola. Thanks for the feedback. Nice that we arrived at the same place! Yes, I was only testing on Qt 5.15.x so I missed that. I guess something like this would make it work on all versions of Qt 5 and 6:
As I described above, I'm not sure it makes sense to try and make this branch support Qt 5 and 6 since the old branch already supports 4 and 5, but if the osgQt maintainers decide to do that then this change is needed. I'm not sure there is much maintenance going on though so maybe we should ask Robert Osfield to let us set up an osgQt6 project? |
Yes, exactly, just a test to properly support Qt5 and Qt6. I am OK with this test. ;-) For me it is very important to properly support Qt5 and Qt6. We have just seen that the cost is also low. Originally the osgQt module was an integral part of OSG then for several years it was extracted from OSG. I think Robert no longer handles this. Moreover, for 2/3 years he seems very busy with VulkanSceneGraph. As you have a fork with just one commit in advance, I think you have to finish the little work that remains (especially with the Qt5/Qt6 test added today just above but also the small differences in the cmake files for proper detection and management of Qt5 or Qt6 libraries -> a new lib with Qt6: OpenGLWidgets, qt5_wrap_cpp/qt6_wrap_cpp, etc...) and then simply submit a Pull Request here. ;-) The osgQt module will then be able to support Qt5 and Qt6. :-)) |
@mtola I'm fine with having Qt 5 and 6 support in the code and I don't think it would be hard to do that in the CMake setup but someone has to make it handle Another complication is that the former "Qt4" approach actually works in Qt5 so some discussion should be had about whether keeping that around in a Qt5 branch has any value. I used that approach for a while in Qt5 until I got the new osgQOpenGL approach to work for my application. If there are no active maintainers here then we should contact Robert about taking this over and make sure we have the Qt4 support correctly archived in the topic/Qt4 branch before we strip that out. Since I helped motivate the separation of osgQt I don't mind contributing here. |
Hi @mtola and @DeadParrot, I'm the original co-author and still the maintainer on this project but since I changed companies three years ago, I'm no longer daily involved with OpenSceneGraph and Qt projects... |
I handed over management for vsgQt as don't have the required Qt expertise to support the project. If @mathieu needs to pass on the management I'm happy to grant write access to others. I haven't closely followed the various threads/contributions to vsgQt so am not in position to know who would be appropriate to open out write access to. @mathieu could you decide who would be appropriate? Also knowing who would be willing to take over would be useful too. |
I would consider being a co-maintainer on this with @mtola and/or others but my time is very limited and I have no deep OpenGL expertise to offer. |
It was finally decided that in my next project we would no longer use OSG so I will gradually move away from OSG. |
Hi,
|
I forgot to update my comment, it does build when I build OSG myself. I had issues using the Ubuntu package of osg. I build like this
|
On my system I ported the current osgQt master branch code to build with Qt 6. The changes required include:
Qt5
toQt6
and various other updates.The CMake side is messier:
Qt6
branch for now until we merge the CMake bits (if that is what we want to do).In summary, the C++ changes are simple but adding Qt 6 support to the CMake setup is kind of messy. It doesn't make sense to contribute here until there is a consensus on how best to add Qt 6 support and whether to resurrect the Qt 4 approach. Maybe separate osgQt4, osgQt5, and osgQt6 repos would be a better way to go. This/these should also be made a proper OSG companion project with releases tagged and in sync with the OSG version number. Since I got the discussion going on problems with osgQt and Qt versions that contributed to splitting out osgQt I am willing to contribute to making these improvements.
The text was updated successfully, but these errors were encountered: