triplus wrote:One question how did you resolve swig 3 dependency for Trusty?
I enabled the backports for this ppa:
- edit ppa dependencies
- choose backports
triplus wrote:
Or maybe if we go after temporary and experimental Py3/Qt5 PPA. To copy it there.
I think this would be the best option as it doesn't influence the currently quite stable 0.17-daily, but gives us the option to easily test the new dependencies. (But it is for sure quite some work to set up such a package)
With conda I will wait for a pyside2/qt5.9 package, as this hopefully will simplify some packaging.
from pivy import coin
a = coin.SoSeparator()
a += coin.SoCone()
On Ubuntu 16.04 (64bit) after adding the PPA python-pivy package gets upgraded correctly. I could install python3-pivy package without issues. I tested the code and can confirm Arch/Draft workbench starts correctly when using FreeCAD from daily/stable PPA or when using Qt 5 build. And especially when using Python 3 FreeCAD build. In Arch workbench i do get:
iterator should return strings, not bytes (did you open the file in text mode?)
But that is classic Python2/3 related issue and it isn't Pivy related.
creating a line results in the following message:
I don't have debug build of FreeCAD 0.16. In release build from PPA i don't seem to get such messages when creating Draft Line. Therefore maybe that could be Ubuntu 14.04/Swig related?
Anyway good job as having a working Arch/Draft workbench in Python 3 FreeCAD builds and Pivy package available from PPA is a big step forward!
--- a/src/Mod/Arch/ArchProfile.py
+++ b/src/Mod/Arch/ArchProfile.py
@@ -59,7 +59,7 @@ def readPresets():
for profilefile in profilefiles:
if os.path.exists(profilefile):
try:
- with open(profilefile, "rb") as csvfile:
+ with open(profilefile, "r") as csvfile:
beamreader = csv.reader(csvfile)
bid=1 #Unique index
for row in beamreader:
but there are more problems with the arch workbench and python3. Maybe @yorik can have a look at this.
For example:
Running the Python command 'Arch_Wall' failed:
Traceback (most recent call last):
File "~/miniconda3/envs/freecad/Mod/Arch/ArchWall.py", line 221, in Activated
FreeCADGui.Snapper.getPoint(callback=self.getPoint,extradlg=self.taskbox())
File "~/miniconda3/envs/freecad/Mod/Arch/ArchWall.py", line 306, in taskbox
w.setWindowTitle(translate("Arch","Wall options").decode("utf8"))
'str' object has no attribute 'decode'
Running the Python command 'Arch_Wall' failed:
Traceback (most recent call last):
File "~/miniconda3/envs/freecad/Mod/Arch/ArchWall.py", line 221, in Activated
FreeCADGui.Snapper.getPoint(callback=self.getPoint,extradlg=self.taskbox())
File "~/miniconda3/envs/freecad/Mod/Arch/ArchWall.py", line 306, in taskbox
w.setWindowTitle(translate("Arch","Wall options").decode("utf8"))
'str' object has no attribute 'decode'
I noticed this too. My plan was just to remove decode() because QWidget.setWindowTitle(translate(...)) is called without decode lots of other places. I just didn't know if it wold have unintended side effects with python2.
Edit: I found the answer. The translate function already takes care of it. Actually I'm confused...don't know why encode is used
Looking at the code i guess in Python 2 convenience function for Qt translator returns byte string encoded in UTF-8. Therefore i do feel decode() attribute will need to be preserved for Python 2 strings. Something like:
try: # Python 2
s = string.decode("utf-8")
except AttributeError: # Python 3
s = string
When porting my modules i went down this road for now. But the convenience function for Qt translator wasn't involved. If decode() attribute would be omitted i am guessing this could be the result when using translated strings in Python 2:
But i don't have deep knowledge of convenience function for Qt translator. And understanding Python 2/Python 3 byte/string situation can be challenging by itself at times.
Or i guess in convenience function for Qt translator .decode("utf8") attribute could in addition be appended. But only when returning Python 2 string. And that would remove the need to do the check explicitly whenever calling the translator function. And decode() attribute shouldn't be used anymore in the code as everything would be done in translator function in the first place.
Thank you triplus. I understand the encode/decode usage now. I think the easiest solution would be add a new utility function named something like "as_utf8" that would only call decode("utf8") in python2 because I see that decode() is not always called in the same place as DraftTools.translate. That way I could blindly replace str.decode("utf8") with as_utf8(str).
Sorry to hijack this thread, I guess I should have started this conversation in the py3 porting thread.
Yes this is how i understand it. But note that i only studied this for a few days for the purpose of porting my modules. And no translations where involved. Therefore there could be more to it or maybe things are resolvable in an easier way. I will likely use such function myself in the future for my modules but basically:
I think we already had a discussion about a centralized translate function. This stuff comes up again and again, so in my mind it would make sense to have a centralized function available. It would definetly simplify porting to new dependencies, as the same stuff doesn't have to be done in all kind of modules.
I think the translate function here should work with (qt4, qt5) X (py2, py3).