You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the binding generation step of compilation, shiboken2 is misidentifying the signals definitions of the CutterCore class. Instead of templating out signal instances, shiboken appears to be interpreting the signal definitions simply as 'public' functions.
I spent some time investigating this yesterday & today, but I am not intimately familiar with the actual generation of PySide bindings. I tried a few random things to try and understand what could be the issue, but could not figure out what was going on.
more verbose shiboken erros/warnings/logging
removing the Q_GLOBAL_STATIC definition
moving the signals section earlier in the class definition incase there was some weird parsing issue
deleting the additional CutterCore definition/prototype at the top of the header
Below is a contrived example of shiboken & signals working properly. Maybe it can be used to help determine if it is an issue with the cutter build env:
Environment information
Describe the bug
During the binding generation step of compilation, shiboken2 is misidentifying the
signals
definitions of theCutterCore
class. Instead of templating out signal instances, shiboken appears to be interpreting the signal definitions simply as 'public' functions.eg:
This is completely wrong.
functionRenamed
should not be directly callable by either C or Python code.As a result, it is impossible to interface with the
CutterCore
signals from python.To Reproduce
The code snippet below does not work because
functionRenamed
is not a signal instance:I would expect the type of
functionRenamed
to be the same as say a push buttonclicked
signalAdditional context
I spent some time investigating this yesterday & today, but I am not intimately familiar with the actual generation of PySide bindings. I tried a few random things to try and understand what could be the issue, but could not figure out what was going on.
Below is a contrived example of shiboken & signals working properly. Maybe it can be used to help determine if it is an issue with the cutter build env:
https://blog.basyskom.com/2019/using-shiboken2-to-create-python-bindings-for-a-qt-library/
The text was updated successfully, but these errors were encountered: