In previous discussions (e.g. this one) it was pointed out that we couldn’t really consider adding support for Qt6 until version 6.2 was released, with its inclusion of QtWebEngine (needed for Start). So, 6.2 is now available, and the Qt Company claims that basically everything that was in 5.15 is now in 6. Technologically speaking, it appears that the path is clear for us to start adding support. Has anyone begun the process of looking into what changes we will need to make? Are there other sticking points to be aware of?
First thing to look at is licensing.
Then if it’s OK, I guess it’s straight forward to have a test build with Qt 6.
Then if we plan to totally move to it, we have to have some spare time as from around 6.5, Qt will probably start announcing future obsolete API and that’s always good to not wait too much to fix this.
Finally before moving, we probably have to evaluate changes on PySide that will likely break the Python part (official and addons). This is IMO the biggest uncertainty along behavior of OpenGL code.
Did you check? https://doc.qt.io/qt-6/portingguide.html
I think we would need an official 0.20 release first, as QT5 was the default from this version on. v0.19 used QT4 by default (see the docs https://wiki.freecadweb.org/Compile_on_Linux)
v0.19 → Python2 and QT4
v0.20 → Python3 and QT5
v0.21 → Python3 and QT6
Or there is a deliberate project decision to jump from default v0.19/Py2/QT4 directly to v0.20/PY3/QT6 with the version change and skip QT5 with official release versions.
What would be wrong about going directly from qt4 to qt6? FreeCAD’s release schedule has no relation with qt’s. Also, does working to support qt6 mean we need to drop support for qt5? I don’t think that’s the case.
Absolutely not – just as we supported both Qt4 and Qt5 simultaneously, I think we’ll support Qt5 and Qt6 simultaneously for some time. Qt6.2 and Qt5.15 are very similar in terms of feature availability and structure, so we may be able to support Qt 5.15 for a long time.
The Qt 6 open source license is LGPL3. To my knowledge we don’t make custom modifications to Qt itself as part of our distribution, and we always link to Qt as a shared library. My understanding of the LGPL is that we can link to it without problems, and without it affecting our own choice of license.
It’s the same license than qt5 so if there is any issue using qt6, then we are already making a violation with qt5 
but obviously I don’t think there is any
I think the one change is that they will no longer have LTS versions for open source, LTS is only for their commercial customers. Since we’ve never pegged to an LTS version, I don’t think that will affect us (except insofar as it affects what Linux distros decide to do, of course). Are any distros including Qt6 yet?
arch and it’s derivatives as expected: https://archlinux.org/packages/extra/x86_64/qt6-base
but anything that isn’t rolling will likely suffer without the point releases
My thinking is “newer is not everytime better”.
So if there are no new “functions” or more bug fixes and OS compatibility improvements, targeting to QT6 is at least premature.
Not counting that many people are using Debian derivative, where “bleeding edge libraries” are not the “normal way” of putting in the OS.
Not speaking about Red Hat derivatives, that use even more “old” libraries.
Better to concentrate on other things, like “fixing bugs” and “extend functionalities” as Qt is dealing with “interface only”, and maybe using more version will be “more work” for developers.
PySide2 is used, but is exposed with old Pyside1 interface, so
But if there are great improvements in “rendering speed” with new Qt6 maybe a “more quick” adoption would be a “real advancement”.
Side note, I’m using Arch derivative, but I use AppImage, so no problem on my side, different thing would be if many distributions will adopt Qt6 as “standard Qt version”.
Regards
Carlo D.
Per repology:
I happened to notice that Spyder uses QtPy, which appears to work with both Qt5 and Qt6. It might be worth a look if someone hasn’t already done so.
So we could guess that at least 5.12 something is the minimal version that will do the job for most used distribution around. (Excluding testing and Arch derivative).
Strange enough there is no Linux Mint, that seems so popular, (but being an Ubuntu derivative, it will use 5.12.x).
It will be interesting having an idea of what is the most used Linux distros that are used by FreeCAD users. (sorry for the bad phrase with most use… in it.)
At least on a developers view it will help to focus on “real userbase needs”, as it is frustrating maybe working on Qt6 and see that maybe only 10% of user base will use it and 90% have no mean to use it on his distribution (not taking in account that many Linux users could use AppImages).
As there are many discussion around and some “bug reports” (done on forum) about errors that are related to the use of “distribution supplied” version of FreeCAD, that sometimes are “old and not too up to date”.
As usual IMHO
Regards
Carlo D.
Maybe we can have a Qt6 branch? 
It actually doesn’t matter if it’s “better”: it only matters that we expect it to replace Qt5 eventually (a decision that’s out of our hands), so at some point we won’t really have a choice about migrating. Since these things can take significant time, it’s best to get started before we are absolutely forced.
Qt 6 was designed to basically be Qt 5.15, but with a bunch of under-the-hood changes, so I don’t think the step from 5.15 (which we support) to 6.2 is that huge. We made it from Qt4 to Qt5, I have no doubt we’ll successfully navigate this transition as well.
Yes, and that why I appreciate you bringing this up for discussion. Being pro-active for stuff like this saves everyone stress in the future.
Taking a look at different projects that leverage qt6:
Scribus https://github.com/scribusproject/scribus/search?q=qt6&type=commits
MuseScore: https://github.com/musescore/MuseScore/pull/10108
I see your point, and I will share this vision, from this point of view.
My consideration was to see also “user needs”, before doing the change, that is another “point of view”, that some people seems to ignore. (Not you to avoiding misunderstanding).
But as said I’m using AppImage so whatever Qt version my distribution is using is not vital to run Qt. (But using Arch “quick adoption” of new library is a well established distribution behaviour).
Maybe that the “quick” adoption of newer Qt versions in distribution that usually rely on “old libraries” is related to KDE being one of the main DE around, (Maybe even LxQt or whatever is called now).
But this is clearly OT so I’m stopping here.
Regards
Carlo D.
JFI since 3 years there is a critical bug that seems related to Qt5 and openGL which leads to graphical crash on Raspberry PI4 boards with the official RPIOS 32B OS.
Hence RPI users (makers/students communiqty) can not experience FC since about 3 years (from RPIOS32B repo I mean), and IMO it’s too bad.
It would be great to experience Qt6 then see if it fixes this bug hopfully 
Keep forward! 
Edit: is → seems
Do you have a link to the upstream Qt5 bug?