example 10.2 not working with soqt

[looooo]

PySide.QtCore.Qevent is not properly wrapped:
<pivy.gui.soqt.QEvent; proxy of <Swig Object of type 'QEvent *' at 0x00000187BBBAA8D0> >

[looooo]

looooo@246b859
I get this output with the added example:

Traceback (most recent call last):
<0x7ffd587590c0  at 0x7fbf24eaef80>
  File "/home/lo/projects/pivy/examples/soqt/renderAreaCallback.py", line 9, in foo
    print(event.button())
AttributeError: 'PySide.QtCore.QEvent' object has no attribute 'button'

[InventorMentor]

I found the following bug in soqt.i: Function unwrapInstance is only available in sip, but not in shiboken! In the latter, it is called getCppPointer. Therefore, it should be
shiboken_unwrapinst_func = PyDict_GetItemString(PyModule_GetDict(shiboken), "getCppPointer");

Does this already fix this issue for you on linux64? There is at least one additional bug specific two win64, though, a 32->64 bit address overflow problem with wrapInstance using the official shiboken 1.2.2 because with MSVC even on 64 bit systems an unsigned long is still mapped there to an uint32, not an uint64 (in MSVC this corresponds to an unsigned long long). Since win64 assigns most addresses for applications beyond 4 GB now, this results in an address overflow problem. Cf.
https://bugreports.qt.io/browse/PYSIDE-103
http://lists.qt-project.org/pipermail/pyside/2013-September/001569.html

I'm going to retry whether this fixes my remaining issue(s) with a correspondingly patched version of Shiboken.

[looooo]

Thanks for the information. I tested only with python2 because only there I have a shiboken available. The unwrapInstance was in the file used for python3. Should be updated now.

But the problem with returning the correct subclass of QEvent is still remaining. Yesterday I figuered out, that the typemaps(out) for QEvent are not placed inside the wrapper-cpp-file. The only function which has potential to be the root of the problem for 10.2 can be found here SoQtRenderAreaEventPythonCB(void * closure, QEvent * event)
But I have to admit that I do not really understand the function. No idea how this should return a subclass of an QEvent...

[looooo]

mottosso/Qt.py#53 (comment) there is a difference in wrapping with shiboken and sip. We have to wrap first to a baseobject and then get the classname of the subclass and wrap again.

[InventorMentor]

Yes, I had already tried this suggested solution yesterday evening from the python side (using your example renderAreaCallback.py extended with wrapInstance ported to python 3 from
http://nathanhorne.com/pyqtpyside-wrap-instance/
buton win64 wrapInstance gives me the address overflow problem with the official shiboken.
However, a pure C++ solution would be much nicer, anyhow, linking against libshiboken, just relying on the current SWIG-part but addtionally converting converting the swig-pointer to PySide ones (not invoking the currently crashing PyEval_CallObject that apparently needs to be wrapped with gilstate ensure() / release according to some blogs [however, still crashed for me, presumably due to win64 address overflow], since when trying to wrap/unwrap in SoQt.i using Shiboken this call to reentering the python interpreter is not thread safe but it should be! It could be entirely avoided, however, on the C side in SoQt.i by calling Shiboken::createWrapper(qobject, /*python owns*/ false); and adding a compile time dependency to libshiboken; please cf.
http://lists.qt-project.org/pipermail/pyside/2012-September/000647.html

[looooo]

However, a pure C++ solution would be much nicer, anyhow, linking against libshiboken, just relying on the current SWIG-part but addtionally converting converting the swig-pointer to PySide ones...

I don't think relying on c++ shiboken library will simplify our lives. As the remaining issue here should be quite solveable, I will try to do so for linux. Maybe I have time to look at windows afterwards.

[InventorMentor]

Solveable, yes, definitely (either on the python [application] side using Nathan's function or much nicer transparently in SoQt.i). Correctness including thread safety first, i.e. also wrapping the reentrant calls to the python interpreter PyEval_CallObject in SoQt.i with gil ensure/release, however, this solution once it is working should add considerable and unnecessary run-time overhead, e.g. when generating many events by moving the mouse in SoQt and wrapping these events for PySide using run-time-only dependecies to shiboken and locking the gil each time and swapping threads going back an forth. The current SWIG "fallback" solution in SoQt.i already works fine on win64, only examples 9.1 (keyboards event pressing 'p' for printing) and 10.2 do not work with the current SWIG fallback and it is not possible to embed SoQtExaminerViewer in a PySide application which is the major issue from a pure python application development point of view. Just my two cents. Unfortunately, I will only find time again tomorrow afternoon at the earliest to get on to patching shiboken for win64. So long, all the best, Peter

[looooo]

Solveable, yes, definitely (either on the python [application] side using Nathan's function or much nicer transparently in SoQt.i)

the solution of Nathan still doesn't work for us. The problem is that a QEvent is not a QObject and therefor has no method to get it's subclass name. So somehow we have to get the subclass-name from the pure QEvent object. This not necessarily have to be done in python. I would simple call the corresponding python functions with the python-capi...

The current SWIG "fallback" solution in SoQt.i already works fine on win64, only examples 9.1 (keyboards event pressing 'p' for printing) and 10.2 do not work with the current SWIG fallback and it is not possible to embed SoQtExaminerViewer in a PySide application which is the major issue from a pure python application development point of view.

9.1 uses a SoEventCallback. I do not have insights in how the coin-callback-mechanism works, but example 10.2 could be simple solved by using also a coin.SoEventCallback. For me the absence of the possibility to set the callback directly is not a big problem.

in SoQt.i with gil ensure/release, however, this solution once it is working should add considerable and unnecessary run-time overhead

This is true for python callbacks anyway. But simple interactions are quite possible. eg: https://forum.freecadweb.org/viewtopic.php?f=22&t=21808#p169625

[looooo]

maybe it's also interesting how quarter translates the events to pivy/coin:
https://github.com/looooo/pivy/blob/master/pivy/quarter/devices/DeviceManager.py#L52L64

[looooo]

it's actually listed as a bug for shiboken:
https://bugreports.qt.io/browse/PYSIDE-31?jql=project%20%3D%20PYSIDE%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20assignee%20ASC%2C%20priority%20DESC

so I would say, we should use SoEventCallbacks for example 10.2 to workaround and make a note that QEvents are not handled properly with pyside.

[looooo]

on linux 10.2 works now. I also added a option to run the example with SoCallBack workaround:
python 10.2.setEventCB.py coin Maybe you can test this with windows.

[InventorMentor]

What an amazing contribution! Excellent work, well done! I reckon I still have to patch shiboken on win64, however, since I still receive the known address overflow problem testing example 10.2. Could you please fix just one minor issue specific to compilation with msvc14: in line 107 and 112 of SoQt.i the char* return type needs an additional const in order to be successfully compiled with msvc:
template <typename T> const char* get_typename(T& object)
I look forward to testing your contribution. Presumably I will only find enough time for that however, not before Thursday morning :-|

[InventorMentor]

Could you please commit a win64 specific modification to Inventor/misc/SoBase.i
unsigned long long __hash__() { return (unsigned long long) $self; }
otherwise $self - i.e. an SoBase object's 64-bit this pointer - is going to be truncated to 32-bit (cf. compiler warning below) when invoking the __hash__ function on win64. This shouldn't matter on linux64, since (unsigned) long there is already a 64 bit address. Unfortunately, there are still more such 64-bit addressing problems lurking around ... I'll post my current problems in a separate comment.

PS: The compiler warning that is going to be fixed by this is
pivy\coin_wrap.cpp(5466): warning C4311: 'type cast': pointer truncation from 'SoBase *' to 'long'

[InventorMentor]

To this end, I had no success with running example 10.2 in just fixing the 64-bit addressing problem in shiboken's 1.2.2 wrapInstance function as suggested by the Maya community. Therefore, I decided to also build PySide 1.2.4 with a patched shiboken 1.2.4 as described below resulting in even more address overflow problems with all of the examples :-( maybe FreeCAD makes use of a better implementation of PySide on win64?

Here is what I tried to this end in a more detailed description:

Following the discussion in
https://www.mail-archive.com/search?l=pyside@qt-project.org&q=subject:%22Re%5C%3A+%5C%5BPySide%5C%5D+Shiboken+Large+Address+Bug%22&o=newest&f=1

and applying the fix suggested in
https://bugreports.qt.io/browse/PYSIDE-191

by

adding a line for a missing type declaration:
<primitive-type name="unsigned long long" />

and changing signature of wrapInstance to:
<add-function signature="wrapInstance(unsigned long long, PyType)" return-type="PyObject*">

this didn't fix the Overflow issue with example 10.2, however. Therefore, instead of using Chris Gohlke's prebuild win64 wheel for PySide 1.2.4, I decided to build one myself including the shiboken 64-bit address patch in wrapInstance above by

... cloning PySide from:
https://github.com/krrr/PySide-setup

... building it with:
C:\opt\libs\pyside-1.2.4>python.exe setup.py bdist_wheel --ignore-git --qmake=c:\Qt\4.8.7_msvc14\bin\qmake.exe --openssl="C:\Program Files\OpenSSL\bin"

(required some minor adjustments to setup.py for python 3.6)

... successfully built me a PySide wheel with the patched shiboken wrapInstance:
C:\opt\libs\pyside-1.2.4\dist\PySide-1.2.4-cp36-cp36m-win_amd64.whl

after its pip-installation to
python-3.6.1.amd64\Lib\site-packages\PySide

I had to copy the following three files shiboken.exe, shiboken-python3.6.dll, shiboken.pyd
one directory up directly into directory site-packages in order to directly support import shiboken in my python3 installation instead of from PySide import shiboken.

[InventorMentor]

Running python 10.2.setEventCB.py caused after 31 ms the following

Unhandled exception at 0x00000000748DAE6F (QtCore4.dll) in python.exe: 0xC0000005: Access violation reading location 0x00000000584A52E8.

raised in line 393 in file soqt-1.5.0\src\Inventor\Qt\SoQtComponent.cpp:
PRIVATE(this)->parent->installEventFilter(PRIVATE(this));

Callstack:
QtCore4.dll!00000000748dae6f() Unknown
soqt1.dll!SoQtComponent::SoQtComponent(QWidget * const parent, const char * const name, const int embed) Line 393 C++
soqt1.dll!SoQtGLWidget::SoQtGLWidget(QWidget * const parent, const char * const name, const int embed, const int glmodes, const int build) Line 179 C++
soqt1.dll!SoQtRenderArea::SoQtRenderArea(QWidget * parent, const char * name, int embed, int mouseInput, int keyboardInput) Line 887 C++
_soqt.cp36-win_amd64.pyd!00007ff99670eba1() Unknown

I receive the same exception now when trying to run all other SoQt examples.

[InventorMentor]

With trying python 02.1.HelloCone.pyw

OverflowError
TypeError: You need a shiboken-based type.
TypeError: You need a shiboken-based type.
TypeError: You need a shiboken-based type.

[looooo]

pyside for python3.5 is not really released. It works for linux, but needs some patching on windows. As far as I can tell, the conda version is working quite fine on windows. Maybe you can have a look at there recipe:
https://github.com/conda-forge/pyside-feedstock/blob/master/recipe/bld.bat
https://github.com/conda-forge/pyside-feedstock/blob/master/recipe/meta.yaml#L20

If we could setup a conda-recipe for soqt we could also build pivy with soqt on conda. Currently I only build coin for conda. This would allow to use pyside from conda...

[looooo]

I have successfully setup a conda-recipe for soqt on linux. On windows this doesn't work. Do you know how to compile soqt on windows?
recipe can be found here: https://github.com/looooo/FreeCAD_Conda/tree/master/soqt
bld.bat is the install-script for windows.

[InventorMentor]

Yes, I do, employing a msvc14 solution for python 3.6 that should also work with python 3.5 after some minor tweaks. I have also created a working msvc10 solution for python 3.4. Would this be good enough for you? Otherwise I could prepare a qmake project file or a corresponding CMakeList.txt if this would be of any help. To this end I have no experience with conda, yet.

N.B.: CPython versions on windows (and custom packages built for them) unfortunately depend on specific versions of the msvc runtime as documented here: https://wiki.python.org/moin/WindowsCompilers - msvc is available as a free community edition (requiring a shocking 8 gb of disk space) but at least it ships with the x64 compiler included by default. The (commercial) msvc10 pro also ships with an x64 compiler, however, the free msvc10 community edition doesn't / ships with a 32-bit x86 compiler only. Neverthless, there is a corrsponding freely available platform sdk available with x64 compiler support for msvc10. However,, I got the impression the sdk's C runtime was slightly different from CPython's 3.4 one which would lead to unexpectedruntime problems with custom build packes. Anyhow, welcome to the brave new windows world. I'm still shocked about their decision to make long on win64 an int32_t instead of an int64_t as was reasonably decided for linux64. This decision will cause a lot of crashes, trouble and demage when porting most well establised C code to more current 64 bit versions of windows :-(

It would be great if conda was hiding all these unnecessary build complexities for building CPython packages on windows ...

[looooo]

conda is quite a nice tool. It simplifies the build process. (At least it's my impression) We have already setup all dependencies of freecad as conda recipes... There are also very good documentation of conda out there. If you want I can give you some references....

Today I also tried the pivy binding of soqt with python3. (Previously I always used python2 to test the pyqt->pyside port) And there are still problem with 10.2.
So my roadmap is to:

1. get soqt bindings with pyside and python3.5 working on linux
2. get soqt compiled on windows
3. get soqt bindings with pyside and python3.5 working on windows

it would be nice if you could give me some instructions how to build soqt on windows. There is a cmake-branch available https://bitbucket.org/roboticslibrary/soqt/src, but there were some problems with the building. So the options are:

1. use/(fork) the cmake branch and repair the not working stuff. (actually I don't think it is much work) ->cmake should be straight forward to use on windows
2. use the tratitional install (.configure) (but I have no idea how to use it)

[looooo]

ok I know now how to run the ./configure in windows:
but the ./configure gives me now this errormessage:

configure: error: no acceptable ld found in $PATH

[InventorMentor]

Thanks for the information and that I may assist with your roadmap. Just out of my memory, configure relies on autotools and therefore on windows is only supported by the mingw compiler (already shipping with the WinPython distribution for example). Mingw has the advantage on windows that its build outputs do not depend on python version / msvc depended compiler runtimes but are self-contained executables and dlls in this respect. However, I'm unsure whether using it would be a good idea and I haven't done so on windows, since it does not seem to be the default way for building cpython packages on windows that depend on external shared libaries / dlls (cf. e.g. the well known python package repository for windows maintained by Chris Gohlke @ uci). Neverthless, some people manage to build dll-depended cpython packages for windows using mingw that are not specific to a particular cpython version. Therefore, I suggest that I transfer my current msvc14 solution to a qmake pro file (since soqt is for usage with qt anyhow) or modify the existing cmake-branch. It might become Saturday though before I will find enough time for that ...

[looooo]

with a minimal change soqt compiles for me on linux with cmake:
https://github.com/looooo/soqt/commit/548eacfcf82d2082480053d70c986042a269c3d6

but compiling the version I uploaded to github reports missing files. This is quite strange. Also creating a compressed file doesn't work. No idea whats wrong there.

[ 37%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtLightSliderSet.cpp.o
/home/lo/conda/conda-bld/soqt_1495181428356/work/soqt/src/Inventor/Qt/SoQtLightSliderSet.cpp:34:50: fatal error: Inventor/Qt/moc_SoQtLightSliderSet.icc: Datei oder Verzeichnis nicht gefunden
 #include <Inventor/Qt/moc_SoQtLightSliderSet.icc>

[looooo]

building directly from the source doesn't show any SoQtLightSliderSet.cpp

[  2%] Generating src/Inventor/Qt/moc_SoQtComponentP.icc
[  2%] Generating src/Inventor/Qt/moc_SoQtGLWidgetP.icc
[  4%] Generating src/Inventor/Qt/widgets/moc_SoQtThumbWheel.icc
[  5%] Generating src/Inventor/Qt/moc_SoQtMaterialList.icc
[  6%] Generating src/Inventor/Qt/moc_SoQtP.icc
/home/lo/git/soqt/src/Inventor/Qt/SoQtMaterialList.cpp:0: Note: No relevant classes found. No output generated.
[  8%] Generating src/Inventor/Qt/moc_SoQtMaterialSliderSet.icc
[  9%] Generating src/Inventor/Qt/moc_SoQtSliderSetBase.icc
[ 10%] Generating src/Inventor/Qt/moc_SoQtSignalThread.icc
[ 12%] Generating src/Inventor/Qt/moc_SoQtTransformSliderSet.icc
[ 16%] Generating src/Inventor/Qt/viewers/moc_SoQtFullViewerP.icc
[ 16%] Generating src/Inventor/Qt/viewers/moc_SoQtExaminerViewerP.icc
[ 16%] Generating src/Inventor/Qt/viewers/moc_SoQtPlaneViewerP.icc
[ 17%] Generating src/Inventor/Qt/widgets/moc_QtNativePopupMenu.icc
[ 19%] Generating src/Inventor/Qt/widgets/moc_SoQtGLArea.icc
Scanning dependencies of target SoQt
[ 20%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQt.cpp.o
[ 21%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtComponent.cpp.o
[ 23%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtGLWidget.cpp.o
[ 24%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtImageReader.cpp.o
[ 26%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtSignalThread.cpp.o
[ 27%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/6DOFEvents.cpp.o
[ 28%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtDevice.cpp.o
[ 30%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtInputFocus.cpp.o
[ 31%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtKeyboard.cpp.o
[ 32%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtMouse.cpp.o
[ 34%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/ExaminerViewer.cpp.o
[ 35%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/FullViewer.cpp.o
[ 36%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/PlaneViewer.cpp.o
[ 38%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/widgets/QtNativePopupMenu.cpp.o
[ 39%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/widgets/SoQtGLArea.cpp.o
[ 41%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/widgets/SoQtThumbWheel.cpp.o
[ 42%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoAny.cpp.o
[ 43%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtCommon.cpp.o
[ 45%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtComponentCommon.cpp.o
[ 46%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtCursor.cpp.o
[ 47%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtGLWidgetCommon.cpp.o
[ 49%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtObject.cpp.o
[ 50%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/SoQtRenderArea.cpp.o
[ 52%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtDeviceCommon.cpp.o
[ 53%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtInputFocusCommon.cpp.o
[ 54%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtKeyboardCommon.cpp.o
[ 56%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/SoQtMouseCommon.cpp.o
[ 57%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/devices/spwinput_x11.cpp.o
[ 58%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/editors/SoQtColorEditor.cpp.o
[ 60%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/editors/SoQtMaterialEditor.cpp.o
[ 61%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/engines/Engines.cpp.o
[ 63%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/engines/Format.cpp.o
[ 64%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/engines/RadioGroup.cpp.o
[ 65%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/ClickCounter.cpp.o
[ 67%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/ColorEditor.cpp.o
[ 68%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Frame.cpp.o
[ 69%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Image.cpp.o
[ 71%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Label.cpp.o
[ 72%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/MaterialEditor.cpp.o
[ 73%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Nodes.cpp.o
[ 75%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Pane.cpp.o
[ 76%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Position.cpp.o
[ 78%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/RadioButton.cpp.o
[ 79%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/SceneTexture2.cpp.o
[ 80%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Slider1.cpp.o
[ 82%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Slider2.cpp.o
[ 83%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/ToggleButton.cpp.o
[ 84%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/Translation.cpp.o
[ 86%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/ViewpointWrapper.cpp.o
[ 87%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/nodes/ViewportFix.cpp.o
[ 89%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/SoQtConstrainedViewer.cpp.o
[ 90%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/SoQtExaminerViewer.cpp.o
[ 91%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/SoQtFlyViewer.cpp.o
[ 93%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/SoQtFullViewer.cpp.o
[ 94%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/SoQtPlaneViewer.cpp.o
[ 95%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/viewers/SoQtViewer.cpp.o
[ 97%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/widgets/SoAnyThumbWheel.cpp.o
[ 98%] Building CXX object CMakeFiles/SoQt.dir/src/Inventor/Qt/widgets/SoQtPopupMenu.cpp.o

[InventorMentor]

The editor widgets for material properties and setting up a directional light were never ported to SoQt 1.5 and are not needed by most people, anyway, these days, since e.g. Qt includes now a very nice default widget for selecting colors (QRGBColorChooser if I remember correctly). Therefore, these legacy editors are also not part of linux packages of SoQt. You may want to just comment these out of the CMakeList ... (they are legacy from SoQt 1.2 and are based on Qt3 or even Qt2 and nobody saw a need to port them to Qt4. Once an SoQt-based ExaminerEmbed example will work with PySide the functionality of these legacy editors could very easily be replaced from the application side using QWidgets if needed.)

[InventorMentor]

I've decided to derive a qmake .pro file from my current msvc14 solution for SoQt-1.6.0a. Slowly, I'm getting there. It compiles fine now using nmake makefiles, however, I still get some linker errors. While porting the build system to qmake, I've found and fixed a win64 address trunctation problem in template file
soqt-1.6.0\src\Inventor\Qt\common\SoGuiComponentCommon.cpp.in
where unsigned long needs to be replaced multiple times with size_t for the lookup of QWidget addresses in a dictionary. However, this did not fix yet my problem with example 10.2 reported above. I'll continue to work on the linker problem tomorrow and hope to provide a win64-msvc compatible qmake pro file then. Best wishes

PS: The same fix needs to be applied in \soqt-1.6.0\src\Inventor\Qt\SoQtComponent.cpp

[InventorMentor]

The following qmake .pro successfully built me both soqt1.dll and soqt1.lib calling nmake from the "VS2015 x64 Native Tools Command Prompt":

# soqt1.pro
# tested with QMAKESPEC=win32-msvc2015 and QMake (2.01a) (Qt 4.8.7) on 64-bit Windows 10
# using x64 native compiler toolset applied with: %QTDIR%\bin\qmake soqt1.pro

TEMPLATE = lib
TARGET   = soqt1
QT      += gui opengl
CONFIG  += qt warn_on thread shared release
CONFIG  -= app_bundle uic

COINDIR       = /opt/libs/coin-4.0.0
SOQTDIR       = /opt/libs/soqt-1.6.0
SOQT_SRC      = $${SOQTDIR}/src
SOQT_MSVC_SRC = $${SOQTDIR}/build/msvc14/src

HEADERS = \
# Private Headers (excluded from build)
#  devices local includes
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoGuiDeviceP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoGuiInputFocusP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoGuiKeyboardP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoGuiMouseP.h \
$${SOQT_SRC}/Inventor/Qt/devices/SoQtDeviceP.h \
# $${SOQT_SRC}/Inventor/Qt/devices/SoQtLinuxJoystickP.h \
#  engines local includes
$${SOQT_MSVC_SRC}/Inventor/Qt/engines/SoGuiEngines.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/engines/SoGuiFormat.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/engines/SoGuiRadioGroup.h \
#  nodes local includes
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiClickCounter.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiFrame.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiImage.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiLabel.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiNodes.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiPane.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiPosition.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiRadioButton.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiSceneTexture2.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiSlider1.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiSlider2.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiToggleButton.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiTranslation.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiViewpointWrapper.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiViewportFix.h \
#  Qt local includes
$${SOQT_MSVC_SRC}/Inventor/Qt/SoGuiComponentP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoGuiGLWidgetP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoGuiP.h \
#$${SOQT_SRC}/Inventor/Qt/SoQtSignalThread.h \
#  src local includes
# $${SOQT_MSVC_SRC}/config.h \
$${SOQT_MSVC_SRC}/config-debug.h \
$${SOQT_MSVC_SRC}/config-release.h \
$${SOQT_SRC}/qt-config.h \
$${SOQT_MSVC_SRC}/soqtdefs.h \
#  viewers local includes
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoGuiExaminerViewerP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoGuiFullViewerP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoGuiPlaneViewerP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoGuiViewerP.h \
# Public Headers
#  Inventor/Qt headers
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQt.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtBasic.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtComponent.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtCursor.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtGLWidget.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtObject.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtRenderArea.h \
#  Inventor/Qt/devices headers
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtDevice.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtKeyboard.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtMouse.h \
#  Inventor/Qt/editors headers
$${SOQT_MSVC_SRC}/Inventor/Qt/editors/SoQtColorEditor.h \
#  Inventor/Qt/nodes headers
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiColorEditor.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SoGuiMaterialEditor.h \
#  Inventor/Qt/viewers headers
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtConstrainedViewer.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtExaminerViewer.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtFlyViewer.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtFullViewer.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtPlaneViewer.h \
#$${SOQT_SRC}/Inventor/Qt/viewers/SoQtPlaneViewerP.h \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtViewer.h \
#  Inventor/Qt/widgets headers
$${SOQT_MSVC_SRC}/Inventor/Qt/widgets/SoQtPopupMenu.h
# $${SOQT_SRC}/Inventor/Qt/widgets/QtNativePopupMenu.h \
# $${SOQT_SRC}/Inventor/Qt/widgets/SoQtGLArea.h \
# $${SOQT_SRC}/Inventor/Qt/widgets/SoQtThumbWheel.h

SOURCES = \
# Source Files
#  Inventor/Qt sources
$${SOQT_MSVC_SRC}/Inventor/Qt/SoAny.cpp \
$${SOQT_SRC}/Inventor/Qt/SoQt.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtCommon.cpp \
$${SOQT_SRC}/Inventor/Qt/SoQtComponent.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtComponentCommon.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtCursor.cpp \
$${SOQT_SRC}/Inventor/Qt/SoQtGLWidget.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtGLWidgetCommon.cpp \
$${SOQT_SRC}/Inventor/Qt/SoQtImageReader.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtObject.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/SoQtRenderArea.cpp \
$${SOQT_SRC}/Inventor/Qt/SoQtSignalThread.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtMouseCommon.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/spwinput_win32.c \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/spwinput_x11.cpp \
#  Qt/devices sources
$${SOQT_SRC}/Inventor/Qt/devices/6DOFEvents.cpp \
$${SOQT_SRC}/Inventor/Qt/devices/SoQtDevice.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtDeviceCommon.cpp \
$${SOQT_SRC}/Inventor/Qt/devices/SoQtInputFocus.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtInputFocusCommon.cpp \
$${SOQT_SRC}/Inventor/Qt/devices/SoQtKeyboard.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/devices/SoQtKeyboardCommon.cpp \
$${SOQT_SRC}/Inventor/Qt/devices/SoQtMouse.cpp \
#  Qt/editors sources
$${SOQT_MSVC_SRC}/Inventor/Qt/editors/SoQtColorEditor.cpp \
#  Qt/engines sources
$${SOQT_MSVC_SRC}/Inventor/Qt/engines/Engines.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/engines/Format.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/engines/RadioGroup.cpp \
#  Qt/nodes sources
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/ClickCounter.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/ColorEditor.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Frame.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Image.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Label.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/MaterialEditor.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Nodes.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Pane.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Position.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/RadioButton.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/SceneTexture2.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Slider1.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Slider2.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/ToggleButton.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/Translation.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/ViewpointWrapper.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/nodes/ViewportFix.cpp \
#  Qt/viewers sources
$${SOQT_SRC}/Inventor/Qt/viewers/ExaminerViewer.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtConstrainedViewer.cpp \
$${SOQT_SRC}/Inventor/Qt/viewers/FullViewer.cpp \
$${SOQT_SRC}/Inventor/Qt/viewers/PlaneViewer.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtExaminerViewer.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtFlyViewer.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtFullViewer.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtPlaneViewer.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/viewers/SoQtViewer.cpp \
#  Qt/widgets sources
$${SOQT_SRC}/Inventor/Qt/widgets/QtNativePopupMenu.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/widgets/SoAnyThumbWheel.cpp \
$${SOQT_SRC}/Inventor/Qt/widgets/SoQtGLArea.cpp \
$${SOQT_MSVC_SRC}/Inventor/Qt/widgets/SoQtPopupMenu.cpp \
$${SOQT_SRC}/Inventor/Qt/widgets/SoQtThumbWheel.cpp

win32 {

    DEFINES += COIN_DLL SOQT_INTERNAL SOQT_MAKE_DLL HAVE_CONFIG_H _WINDLL
    DEFINES -= UNICODE
    INCLUDEPATH += $${COINDIR}/include \
                   $${SOQT_MSVC_SRC} \
                   $${SOQT_SRC}

    Release {
        CONFIG += release
        DEFINES += NDEBUG _NDEBUG SOQT_DEBUG=0
        LIBS += $(COINDIR)/lib/coin4.lib
    }

    Debug {
        TARGET  = soqt1d
        CONFIG -= release
        CONFIG += debug
        DEFINES += DEBUG _DEBUG SOQT_DEBUG=1
        LIBS += $(COINDIR)/lib/coin4d.lib
    }

}

[InventorMentor]

on linux 10.2 works now. I also added a option to run the example with SoCallBack workaround:
python 10.2.setEventCB.py coin Maybe you can test this with windows.

Your workaround for 10.2 with option coin now "sort of" works for me under windows. However, I had to change line 74 in 10.2 from
intersection = (p0 + p1) / 2.0
to
intersection = (p0 + p1) * 0.5
otherwise, I get the following error when clicking the left mouse button in the render area:
TypeError: unsupported operand type(s) for /: 'SbVec3f' and 'float'
I've got no idea why this is so, since this division seems to be well defined in SbVec3f.i

[looooo]

import shiboken works for:

• win7 64 python3.5.3
• win7 64 python3.6.1
• win10 64 python3.6.1
• win10 64 python3.5.3
  I belive the same is true for win8.

actually I made some mistakes previously on windows10. Quarter does work for me. Only 10.2 without coin argument crashes. (Maybe I have installed an older version...)
Also running 10.2 with the coin argunment prints a Overflowerror, which win7 does not.

OverflowError
TypeError: You need a shiboken-based type.
TypeError: You need a shiboken-based type.
TypeError: You need a shiboken-based type.

So maybe again some problems with pyside.

[looooo]

some further observation in win10:

• starting soqt/minimal.py several times will show the viewer sometimes.
• it's definetly a problem with soqt.
• maybe a wrapping issue. But I don't know where it is comming from.

[InventorMentor]

On 64-bit win10, example 10.2 only works as expected for me with option coin when using the swig-based soqt-binding (without an installed shiboken). Without option coin and without shiboken installed manually to Lib\site-packages (to disable the direct import shiboken expected by pivy instead of from PySide import shiboken as provided by the default PySide installation) I receive an

AttributeError: 'QEvent' object has no attribute 'type'
Traceback (most recent call last):
  File "10.2.setEventCB.py", line 140, in myAppEventHandlerQt4
    if anyevent.type() == QEvent.MouseButtonPress:

On 64-bit win10, with shiboken installed manually to Lib\site-packages running example 10.2
gives me with option coin random startup crashes of the application due to 32-bit pointer truncation as reported above and only sometimes when I start 10.2 the render area actually appears but then I get the OverflowError / shiboken-based type error message you reported above. Otherwise, the example is usable when it actually made it to startup. Omitting option coin [as the expected default use case for example 10.2 with shiboken manually installed to Lib\site-packages], however, starts up only occassionaly (randomly) but then I'm unable to draw in the render area and it prints the error message

AttributeError: 'QEvent' object has no attribute 'type'
OverflowError
Traceback (most recent call last):
  File "10.2.setEventCB.py", line 140, in myAppEventHandlerQt4
    if anyevent.type() == QEvent.MouseButtonPress:

In random cases, when example 10.2 does not start up at all with shiboken and crashes directly on startup for me, then the attached post-mortem debugger halted at an exception in this constructor call

SoQtGLWidget::SoQtGLWidget(QWidget * const parent,
                           const char * const name,
                           const SbBool embed,
                           const int glmodes,
                           const SbBool build)
  : inherited(parent, name, embed),
    waitForExpose(TRUE),
    drawToFrontBuffer(FALSE)

however, then the pointers like parent can not be inspected from the debugger with message Variable is optimized away and not available.

PS: Since under 64-bit win10 example 10.2 with option coin apparently always works as expected when import shikoken is not available (just with the swig-based 'fallback' wrapping of pivy.gui.soqt) , I reckon we may exclude libraries Coin3D and SoQt as the source of this issue. Testing a corresponding native C++ example 10.2 implementing a C++ version of myAppEventHandlerQt4(myRenderArea, anyevent) also works reliably and as expected on 64-bit win10, providing further evidence that this issue is not with native Coin3D 4.0.0a, SoQt 1.6.0a, or Qt-4.8.7, but must be with pivy, its's shiboken-based soqt-binding, pyside, or shiboken.

[looooo]

just came across these two warnings:

pivy\coin_wrap.cpp(5467): warning C4311: 'type cast': pointer truncation from 'SoBase *' to 'long'
pivy\coin_wrap.cpp(5467): warning C4302: 'type cast': truncation from 'SoBase *' to 'long'

[InventorMentor]

Test case: running failing example 10.2 on 64-bit win10 with available import shiboken multiple times until it randomly proceeds to show the render area after multiple attempts; The OverflowError reported above is printed in the body of the following failing if statement attempting to call shikobken_wrapinst_func in line 43 of file pivy/Inventor/Qt/SoQtRenderArea.i:

if (!(qev = PyEval_CallObject(shiboken_wrapinst_func, arglist))) {
            PyErr_Print();  // prints "OverflowError"
}

[looooo]

so this is again a problem with the pointer-size? Allthough it is now set to size_t.
regarding this site: https://msdn.microsoft.com/en-us/library/323b6b3k.aspx
size_t can be unsigned __int64 or unsigned integer, depending on the target platform...

[looooo]

unsigned long long has the same problem. If I understand it correctly:
If the wrapping fails (OverflowError) the example works because for the minimal example no pyside type is necesarry. If the wrapping does work, there is a crash (because of wrongly wrapped qt-object)

[InventorMentor]

Working backwards from line 43 in SoQrarenderArea.i, I'll have to insert printf statements to see what is going on and maybe to test assumptions and spot differences against a working scenario on win7 or eventually linux64, since I do not have a debug build of py3, pivy, qt, ... you name it .... therefore, the good old printf debugger should be my best bet ... some Maya folks apparently had a very similar OverflowError: need a shiboken based type ... and recommend as a solution to import shiboken only as from PySide import shiboken - the printf debugger will not be too easy to implement, however, because of the convoluted PyObject structures involved. Maybe you can verify that shiboken gets imorted correctly into pivy on win10 ...

[cgohlke]

... this didn't fix the Overflow issue with example 10.2, however. Therefore, instead of using Chris Gohlke's prebuild win64 wheel for PySide 1.2.4, I decided to build one myself including the shiboken 64-bit address patch in wrapInstance above by ...

FWIW, I have updated my PySide wheels with the shiboken 64-bit address patch. The OverflowError should be fixed.

[InventorMentor]

Dear Chris Gohlke, thank you very much indeed, I'll be most happy to try this. I can confirm that the issue for me on win10 was shiboken.wrapInstance
as I can now confirm on my machine using a minimal test case taken from https://bugreports.qt.io/browse/PYSIDE-103

from PySide import QtCore, shiboken
shiboken.wrapInstance(0xFFFFFFFF, QtCore.QObject)  # Overflow error --> largest 32-bit address, howevsser, this should definitely work on all systems
shiboken.wrapInstance(0x100000000, QtCore.QObject) # Overflow error --> an actual 64-bit address > 4 GB (the first non 32-bit address)

However, a bit surprisingly, a slightly smaller 32-bit address
shiboken.wrapInstance(0xFFFFFFF, QtCore.QObject)
works for me on 64 bit win10.

Now I can test this against your wheel .... I reckon you made my day :-)

[cgohlke]

Works for me:

Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from PySide import QtCore, shiboken
>>> shiboken.wrapInstance(0xFFFFFFFF, QtCore.QObject)
<PySide.QtCore.QObject object at 0x00000143E4F58288>
>>> shiboken.wrapInstance(0x100000000, QtCore.QObject)
<PySide.QtCore.QObject object at 0x00000143E4F583C8>

[InventorMentor]

finally, this minimal test case above also works for me, too :-) Thank you very much indeed! ... now, I'm looking forward to test example 10.2 and examinerEmbed4.py (testing the embedding of a Coin3D / OpenInventor examiner viewer into a PySide application that also failed on 64-bit win10 to this end)

[InventorMentor]

Unfortunately, running example 10.2 still fails for me with an
Unhandled exception at 0x00000000541AADFF (QtCore4.dll) in python.exe
coming from a 32-bit address on my 64-bit win10 machine using 64-bit WinPython 3.6.1.
QtCore.dll is on my system a self-compiled 64-bit msvc14 release dll and lives here (also in the system's search path):
C:\Qt\4.8.7_msvc14\bin\QtCore4.dll

[InventorMentor]

after recompiling pivy, I interestingly receive now a different error message than before:
OverflowError: can't convert negative int to unsigned

[InventorMentor]

@looooo you may want to try and add the following script to pivy/tests:

# shiboken_64bit_test.py
from PySide import QtCore
import shiboken  # as expected by pivy (instead of the default "from PySide import shiboken")

q = QtCore.QObject()
ptr = shiboken.getCppPointer(q)
print("CppPointer to an instance of PySide.QtCore.QObject = 0x%016X" % ptr[0])

# None of the following is expected to raise an OverflowError on 64-bit systems
shiboken.wrapInstance(0xFFFFFFFF, QtCore.QObject)  # largest 32-bit address
shiboken.wrapInstance(0xFFFFFFF, QtCore.QObject) # a regular, slightly smaller 32-bit address
shiboken.wrapInstance(0x100000000, QtCore.QObject) # an actual 64-bit address (> 4 GB, the first non 32-bit address)
shiboken.wrapInstance(0xFFFFFFFFFFFFFFFF, QtCore.QObject) # largest 64-bit address

[looooo]

added your test.

just a side note:

import shiboken # as expected by pivy (instead of the default "from PySide import shiboken")

I think shiboken should be importable directly. At least that was my conclusion from reporting it to conda:
conda-forge/pyside-feedstock#31

the test fails for win10 and ubuntu at:

ERROR: testAdresses (__main__.ShibokenTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "coin_tests.py", line 1226, in testAdresses
    shiboken.wrapInstance(0xFFFFFFFF, QtCore.QObject)  # largest 32-bit address
OverflowError

ps.: same is also true for win7. does this work for you?

[InventorMentor]

Yes, it works for me, but I don't know why. It should have worked with the patch for PySide-103, however, it didn't ... both my patched build based on krrr's PySide and according to your PySide recipe failed for me regarding shiboken wrapInstance. However, Chris Gohlke, suddenly dropped by to the rescue yesterday and provided a python wheel with a PySide that ships with a working 64-bit shiboken for windows ... but there is no source code and I can live without it for my needs .... I reckon FreeCAD's PySide, however, will also need this fix... apparently Autodesk is also publishing a fixed PySide on its website for Maya 2015.

PS: I've also found the bug :-) example 10.2 and examinerEmbed4 now happily work for me on 64-bit win10 ... I still have to investigate things a bit further and need to tidy up ...

[InventorMentor]

btw ... the bug was a type downcast error from a 64-bit address (of a void*) to a (signed 32-bit) int instead of the needed and plattform-independently correct size_t. There may be more such bugs lurking around ... I'll check that and will post a fix within the next couple of days!

[looooo]

wow, that are very good news. thanks for all the work!

[InventorMentor]

Sorry for my late reply. I needed to take a little break away from pivy after diving deep into this issue. Please find my patched versions of pivy/Inventor/Qt/SoQtRenderArea.i
https://www.dropbox.com/s/6v0mmvk3638vdq8/SoQtRenderArea.i?dl=0
and pivy/interfaces/soqt.i
https://www.dropbox.com/s/i2eydxzeixctc80/soqt.i?dl=0
ready for you to download under the above two URLs. Please copy their file contents over their existing versions in your current git clone on branch master and please review a git diff of my changes and check whether you are happy with them and would agree to keep them. All relevant examples including 10.2 (except just examples 9.1 and 12.4, but I'll write seperate issues for these later) now work happily as expected for me under 64-bit Windows 10. Please note that the complete fix to this issue also requires a working 64-bit version of shiboken for windows (e.g. as provided by Chris Gohlke's recent PySide wheels).

I feel it would be really good if we knew how the build these patched wheels ourselves just in case we need to fix more issues in PySide. Also, please note that I've not patched the python2 version pivy/interfaces/soqt2.i, yet. This still needs to be done. My posted fix should also work employing python 3 with win32, linux32 and linux64, however, I couldn't test this. Maybe you have the means to do that. If you are happy with the proposed solution and find it is working also on linux then I'd suggest that you may finally want to close this issue :-)

[looooo]

thanks for your collaboration.
can you give me your e-mail address so I can add you as a contributor.

[looooo]

the pyside problem was patched in the conda-package: conda-forge/pyside-feedstock@bd60246

I think I will try to create pivy-packages for win and linux this weekend and look if the problems on win10 is still there.

@cgohlke do you have a list of patches you use for your pyside-package?

[cgohlke]

@cgohlke do you have a list of patches you use for your pyside-package?

Source code is at http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyside in PySide-1.2.4-vc14-x64.zip.
To fix the OverflowError, see the changes in conversions.h and sbkconverter_p.h.

[looooo]

thanks a lot @cgohlke . The diff of these files can be found here: https://github.com/looooo/pyside-feedstock/blob/master/recipe/win_pointer_conversation_fix.patch

[looooo]

finally this solves 10.2 on windows 10 and conda. That is a big step forward :-)
so what is missing:

• add InventorMentor as contributer of looooo@eee5527
• apply this commit to python2 (looooo@5e1dc41)
• move pyside test in another file (there is still one test failing on win7, can we remove this one?)

[looooo]

@InventorMentor I can add you as author of the mentioned commit later anyway. Just tell me how ou would like to handle this.
I close this issue now as I think this example should work. At least I have tested with conda on:
linux py34, py35, py36
win7, win8, win10