Is see the advantage of merging the QT6 migration branch back into master, when and ONLY when the migration is (nearly) finished and does not yield any major problems.
I can think of a myriad of reasons not to merge intermediate commits of a major framework migration into master. There will probably be only a few devs who will work on this migration. During this process there will inevitably be build breaking errors. Even minor commits could break the build, as the committing dev can not be aware of all possible hickups in all used system/setups etc. Not intentionally of course, but that’s how it works. Now you force these problems onto all other devs who are not directly involved with this migration. That is IMHO a really bad idea.
Now you force these problems onto all other devs who are not directly involved with this migration. That is IMHO a really bad idea.
Nobody is planning on merging untested code onto master, you make a PR, it is tested in all platforms, reviewed, iterated, repeat until done and then it’s merged. I agree if there will be several devs involved a branch should be created once we have an initial PR (no point in doing it now if it’s just going to be the same as master).
I say toponaming is waaaay more important than this, it would be best to have that in first to not get huge conflicts but if there’s no guarantee or estimate for merging that and someone can’t realistically help with toponaming but can help with migration it might be better if they do it anyways, we can’t freeze freecad’s development for a mystical merge that never comes.
If migrating to Qt6 perhaps a discussion about migrating to QML could be had? I think that would be a significantly larger task though, but grouping such work together might make sense from a logical standpoint.
Oh, and I wholeheartedly agree that TNP mitigation is substantially more important. But different devs have different areas of interest/focus so other proposed efforts shouldn’t necessarily be discounted either. I just wish I had more talent with development.
Toponaming is independent of this: no Qt related code should be anywhere near the toponaming code. We should not have any issues with merge conflicts, etc.
I think this discussion is basically moot until there is actually a Qt6 PR to consider – then we can look at how much code we are talking about, and how many PRs we expect it to be. So I circle back to my original question: is there any code in the works? Does anyone have a Qt6 branch we can start looking at?
We will not merge intermediate commits – only functionally complete PRs will be considered.
I remind everyone that git is decentralized by design: you are always welcome to create a branch in your fork and to invite other collaborators to either submit PRs to YOU, or to join a team you give access to that repository. In many respects that is easier than trying to use an “official” branch, since you’d still have to submit PRs to the official branch and wait for them to be reviewed, etc.
At a quick glance we probably don’t want to base any further work on those experiments, since that’s a wholesale replacement of Qt5 with Qt6. What we will ultimately merge needs to support using either, via a switch in cMake.
realthunder can you weigh-in on this topic since you’re working toward a toponaming merge. Should we focus on qt6 post-toponaming or can we do it concurrently?
I use globalStrut as QSize (0,0) (defaults value). I think this is not correct. I don’t know correct values.
P.S. During replace obsolete function I see many files with different newline style (Dos, Unix-way). Also there are different code style formatting. May be we cleanup our code with dos2unix or unix2dos?
No.
It will compile with qt6 only. I made it to see how clazy porting tool work.
If we follow porting guide than we must disable obsolete function for qt5.15 not 5.9. (read my previous post)
in my amateur eyes clazy seems to be aimed at porting to 6 and ditching 5…
this whole story also raises the hypothetical question if fc should still keep pyside - alias, or switch to pyside2 (and lock the door on 4) - sort of implies that also in c one could go for 5 instead of 4 base…
had one edge use case (on linux) where i could not get imports working (forgot what it was - probably a not very important use case), since the fc code base uses pyside imports while in reality the installed package is pyside2…
if someone finds the time, just out of personal interest,
how is the shiboken/pivy deps influenced by 5 or 6 (other than that it obviously has to be complied to matching qt and py versions)?
yes but we can’t take the suggestion, keep those that are compatible with both as is and those qt6 specific inside if else blocks
this whole story also raises the hypothetical question if fc should still keep pyside - alias, or switch to pyside2 (and lock the door on 4) - sort of implies that also in c one could go for 5 instead of 4 base…
the door for qt4 is already closed, minimum supported version is qt 5.9 currently, using pyside2 might be problematic because we now need pyside6 for qt6, perhaps we can have an alias that is set to pyside2 or pyside6 depending on the chosen qt version? I don’t know much of how this part works.
how is the shiboken/pivy deps influenced by 5 or 6 (other than that it obviously has to be complied to matching qt and py versions)?
There is shiboken6, I guess we need pivy compiled against qt6 too.
