Qt4/Qt5 neutral compilation fixes

[jmaustpc]

Here is the latest branch rebased on current master:

What else must be done for the Qt5 port other than that? Maybe we should leave the current master as is and do the complete porting to Qt5 in a separate branch (e.g. yours) but remove all old Qt4 stuff. What do you think?

I read on Phoronix
https://www.phoronix.com/scan.php?page= ... TS-Updates
that qt5.5 will be the default qt on 16.04 but if we still have to support 12.04 where qt4 was the default, then would that make QT5 a dependency? I had a quick Google search and it would seem that QT5 on 12.04 has to be installed from a PPA, unless I am missing something. Doesn’t that mean that we should still support qt4, if possible, until the end of life of 12.04?

[f3nix]

Hi,

Here is the latest branch rebased on current master:

What else must be done for the Qt5 port other than that? Maybe we should leave the current master as is and do the complete porting to Qt5 in a separate branch (e.g. yours) but remove all old Qt4 stuff. What do you think?

to make things clear. Posting that link was my failed attempt at marketing and not a suggestion to merge it.
The qt4-qt5-neutral is all I wanted in current master (less commits to maintain in the transition branch).

To answer your question. Here is my current TODO:
- Fix Property Editor Framework for Qt5 (right now it crashes hard - viewtopic.php?f=10&t=13662) - this one is the most important and difficult
- Port code to PySide2 (btw. is there a good way to support both PySide and PySide2 in one codebase?) (just started so I don't know how easy or how hard it is)
- Move from QHttp to QNetworkAccessManager (Qt4/Qt5 neutral)
- In Qt5, the Q_WS_* macros have been removed. So the code wrapped in it does not compile at the moment.
- I'm sure there is more I don't know about yet

PySide2 is still pre-alpha and to my knowledge no distribution has packages for it. So I think that Qt5-only version would not be an option at this time (maybe one of the goals for 0.17?).

My plan was to keep the qt5-transition-x branches synced with master until they are ready for testing/production use.

Cheers,
Mateusz

[blacey]

What else must be done for the Qt5 port other than that? Maybe we should leave the current master as is and do the complete porting to Qt5 in a separate branch (e.g. yours) but remove all old Qt4 stuff. What do you think?

@f3nix, how is the QT5 port coming? With OCCT7 and SMESH nearly ready, sans some packaging hurdles, it seems QT5 might be another thing to get behind us and you have made great progress to date... I'm happy to try to push things along on the Mac side in parallel if that will help in wrapping this up...

[f3nix]

What else must be done for the Qt5 port other than that? Maybe we should leave the current master as is and do the complete porting to Qt5 in a separate branch (e.g. yours) but remove all old Qt4 stuff. What do you think?

@f3nix, how is the QT5 port coming? With OCCT7 and SMESH nearly ready, sans some packaging hurdles, it seems QT5 might be another thing to get behind us and you have made great progress to date... I'm happy to try to push things along on the Mac side in parallel if that will help in wrapping this up...

Hi,
sorry for a late reply. I'm busy with some other hobbies... Building my new 3d printer takes all my free time

Here is the latest rebased branch (master from today):
https://github.com/f3nix/FreeCAD/commit ... nsition-17

Here are some problems (there are more but I don't have a list yet):
- Property system needs a rewrite (current solution crashes).
- Windows build crashes during start. Do not have time to debug it. (Needs some patches I haven't commited yet to compile).
- Some pure Python workbenches do not load/do not work due to recent changes.
- ...

Feel free to compile it under Mac and report back what works and what doesn't.

Cheers,
Mateusz

[wmayer]

Latest branch: https://github.com/f3nix/FreeCAD/commit ... nsition-24

Add:
https://github.com/f3nix/FreeCAD/commit ... d30e14f060
https://github.com/f3nix/FreeCAD/commit ... fdc3008ac3

See also:
https://github.com/f3nix/FreeCAD/commit ... 2585bb1813
https://github.com/f3nix/FreeCAD/commit ... 4b6717e802
https://github.com/f3nix/FreeCAD/commit ... 03e790ab63

[f3nix]

Hi,
latest branch is this: https://github.com/f3nix/FreeCAD/tree/qt5-transition-25

Rebased on latest master. It finally passes almost all tests (except one) after fixing some previous rebase errors

Cheers,
Mateusz

[wmayer]

latest branch is this: https://github.com/f3nix/FreeCAD/tree/qt5-transition-25

OK, now we come to the dirty part of the migration

In order to keep the changes for PySide2 move at a minimum I think it's best to first rewrite the import statements to be:

Code: Select all

from PySide.QtGui import QWidget, QTreeWidget, QPushButton

Then further down we don't need the module prefix QtGui any more.

[yorik]

I was thinking we maybe could also abstract the PyQt/PySide/PySide2, there is the qtpy package that could become interesting too some day...
Maybe there would be a way to define what gets used at compile time, and make python modules use this? Maybe a member of the FreeCAD module?

[triplus]

As the decision was made to use PySide2 FreeCAD 0.17 (or the version after FreeCAD 0.17 if the needed work won't be done yet) should likely be Python3/PySide2/Qt5 only.

Anything else likely comes down to wasting resources, introducing legacy code in FreeCAD code base and making it really hard for Python/Qt contributors to contribute "bug free" code. As Python2/Python3, PySide/PySide2 and Qt4/Qt5 compatible code must be provided to satisfy the requirements for contribution.

[looo]

+1 for not supporting multiply qt bindings. There are for sure some incompatible things in pyside, pyside2, pyqt4, pyqt5. Better to go for pyside2 only.