Supporting Qt5

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Supporting Qt5

Post by wmayer »

The first one being changing QCoreApplication::translate to QObject::tr, because the Qt docs made it sound like they were equivalent
No, they are not equivalent. QObject::tr adds the string literals into the .ts files with "QObject" as context while with QCoreApplication::translate you can explicitly the context class name which we often need to be properly set because otherwise the translation at runtime is broken.
mrlukeparry
Posts: 655
Joined: Fri Jul 22, 2011 8:37 pm
Contact:

Re: Supporting Qt5

Post by mrlukeparry »

jriegel wrote:Great you look into this. But I feel no need to switch to Qt5. The 5 was mainly driven by Nokias need for mobile platform. I see little to nothing to gain for C++ desktop applications. Or am I wrong!?
Nothing in particular, unless you want to use QML / QtQuick or an updated QtWebkit. The only other changes I think was c++11 support in particular the use of lambda functions for their signal-slot system.

The only thing I liked is the idea of a QML front-end to the 3D View so that we can overlay an interface. No immediate benefits, but I suppose eventually we'll have to migrate...
peterl94
Veteran
Posts: 1001
Joined: Thu May 23, 2013 7:31 pm
Location: United States

Re: Supporting Qt5

Post by peterl94 »

wmayer wrote:No, they are not equivalent.
Okay, thanks for clarifying that.

The only reason I'm trying this is because there are a couple patches for Qt 5 that fix issue #0001408. I don't think there is a need for actually switching to Qt 5, but would you ever consider just having it as an option?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Supporting Qt5

Post by wmayer »

I don't think there is a need for actually switching to Qt 5, but would you ever consider just having it as an option?
As soon as the major Linux distributions have packages for SoQt, PySide, ... based on Qt5 we can support this in FreeCAD, too. And as far as I understand it should be no problem to support Qt4 and Qt5.
User avatar
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Supporting Qt5

Post by jriegel »

The only thing I liked is the idea of a QML front-end to the 3D View so that we can overlay an interface. No immediate benefits, but I suppose eventually we'll have to migrate...
That indeed would be shiny :)
Stop whining - start coding!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Supporting Qt5

Post by DeepSOIC »

Peter! Is it still alive?
I am trying to bring touchscreen gesture support to FreeCAD, and I can't get it working under windows 8.1 so far. It looks like there are substantial improvements in qt5, so I think I might need it.
peterl94
Veteran
Posts: 1001
Joined: Thu May 23, 2013 7:31 pm
Location: United States

Re: Supporting Qt5

Post by peterl94 »

No, not really, but you can use it as a reference. There has been a lot of changes since I did that, and I didn't keep the branch updated. Probably the most significant being the switch to Quarter. I think Quarter works with Qt5 without any modifications, but I'm not sure.

Unfortunately, I didn't know much about Git then, and so I didn't separate the commits well. Commit bcc48322 updates the includes for iisTaskPanel, 40a4a502 is CMake changes, and commit a60446c is everything else :roll:. Most of it was a search and replace: QString::fromAscii and QString::toAscii to QString::fromLatin1 and QString::toLatin1, and Qt::WFlags to Qt::WindowFlags. The other common change was removing the last argument from QCoreApplication::translate calls. (I mistakenly changed it to QObject::tr).

Pretty much the only major roadblock in porting to Qt5 is PySide. Last time I check it wasn't high on their priority list. But anyway, all of the C++ workbenches would still work.
beluga
Posts: 12
Joined: Wed Mar 11, 2015 7:44 am

Re: Supporting Qt5

Post by beluga »

I checked the PySide mailing list, topic PySide is dead? and it certainly seems no one has even started looking at Qt5 for PySide.

One recommendation from the thread:
If you want to go with Qt5, you can either check PyQt5, or go with QML +
Pyotherside. Pyotherside is a C++ bridge which allows you to call Python
code from your QML code. QML is quite good nowadays, and with
pyotherside you may almost not touch javascript. And with Qt Quick
Controls you can use native OS widgets within QML.
There is a thread from October 2014 where several people expressed their interest in helping with Qt5 support, but nothing came of it.

I guess FreeCAD should either switch to PyQt or Pyotherside or bring all those potential contributors from that 2014 ml thread together and organize a Qt5 effort.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Supporting Qt5

Post by wmayer »

Thanks for the links, beluga?
I guess FreeCAD should either switch to PyQt or Pyotherside or bring all those potential contributors from that 2014 ml thread together and organize a Qt5 effort.
PyQt5 is not an option for us because of its GPL license which btw. was the reason to move over to PySide. I have never heard of Pyotherside but this sounds interesting.
beluga
Posts: 12
Joined: Wed Mar 11, 2015 7:44 am

Re: Supporting Qt5

Post by beluga »

wmayer wrote:Thanks for the links, beluga?
I guess FreeCAD should either switch to PyQt or Pyotherside or bring all those potential contributors from that 2014 ml thread together and organize a Qt5 effort.
PyQt5 is not an option for us because of its GPL license which btw. was the reason to move over to PySide. I have never heard of Pyotherside but this sounds interesting.
I'm not sure, if this helps, but apparently there have been some changes in how PyQt handles licensing:
http://lists.qt-project.org/pipermail/p ... 02263.html
Stephan Deibel wrote:
> Most of the more serious and heavily invested current users of PySide
> are there because of licensing issues in PyQt and thus can't just move
> over to PyQt. The key issue is that if someone sells a product with a
> scripting API then PyQt requires paying a per-user licensing fee. Not a
> large one, but it's still a problem for some, for example if you're
> giving away a lot of free licenses on the side, or just want to avoid
> this sort of entanglement. I doubt that is going away, but if it does
> than so may PySide.

I just found out that the above statement (by me, earlier today) is no
longer true!

Licensing for the commercial version of PyQt now allows Python to be
used to script or extend the functionality of the commercial application
by its users. You just need to purchase developer licenses for the
people writing the commercial app itself, and due to Qt commercial
licensing details you need to use the LGPL version of Qt.

See the 7th Q on http://www.riverbankcomputing.com/comme ... icense-faq

I've also had confirmation of this via email from PyQt's author, Phil
Thompson.

I don't know if my prediction that this means the end of PySide is true
either, but it certainly changes the landscape considerably...
Post Reply