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.The first one being changing QCoreApplication::translate to QObject::tr, because the Qt docs made it sound like they were equivalent
Supporting Qt5
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Supporting Qt5
-
- Posts: 655
- Joined: Fri Jul 22, 2011 8:37 pm
- Contact:
Re: Supporting Qt5
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.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!?
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...
Development blog - http://freecadamusements.blogspot.co.uk/
Re: Supporting Qt5
Okay, thanks for clarifying that.wmayer wrote:No, they are not equivalent.
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?
Re: Supporting Qt5
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.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?
Re: Supporting Qt5
That indeed would be shinyThe 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...
Stop whining - start coding!
- DeepSOIC
- Veteran
- Posts: 7896
- Joined: Fri Aug 29, 2014 12:45 am
- Location: used to be Saint-Petersburg, Russia
Re: Supporting Qt5
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.
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.
Re: Supporting Qt5
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 . 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.
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 . 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.
Re: Supporting Qt5
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:
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.
One recommendation from the thread:
There is a thread from October 2014 where several people expressed their interest in helping with Qt5 support, but nothing came of it.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.
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.
Re: Supporting Qt5
Thanks for the links, beluga?
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 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.
Re: Supporting Qt5
I'm not sure, if this helps, but apparently there have been some changes in how PyQt handles licensing:wmayer wrote:Thanks for the links, beluga?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 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.
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...