Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CutterCore signal bindings are generated improperly #1482

Closed
gaasedelen opened this issue Apr 21, 2019 · 3 comments · Fixed by #1530
Closed

CutterCore signal bindings are generated improperly #1482

gaasedelen opened this issue Apr 21, 2019 · 3 comments · Fixed by #1530
Assignees
Labels

Comments

@gaasedelen
Copy link

Environment information

  • Operating System: Ubuntu 18.04
  • Cutter version: 1.8.0, 1.8.1, Latest
  • File format: N/A

Describe the bug

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.

eg:

static PyObject* Sbk_CutterCoreFunc_functionRenamed(PyObject* self, PyObject* args)
{
    ::CutterCore* cppSelf = nullptr;
    SBK_UNUSED(cppSelf)
    if (!Shiboken::Object::isValid(self))
        return {};
    cppSelf = reinterpret_cast< ::CutterCore *>(Shiboken::Conversions::cppPointer(SbkCutterBindingsTypes[SBK_CUTTERCORE_IDX], reinterpret_cast<SbkObject *>(self)));
    int overloadId = -1;
    PythonToCppFunc pythonToCpp[] = { nullptr, nullptr };
    SBK_UNUSED(pythonToCpp)
    int numArgs = PyTuple_GET_SIZE(args);
    PyObject* pyArgs[] = {0, 0};

    // invalid argument lengths


    if (!PyArg_UnpackTuple(args, "functionRenamed", 2, 2, &(pyArgs[0]), &(pyArgs[1])))
        return {};


    // Overloaded function decisor
    // 0: CutterCore::functionRenamed(QString,QString)
    if (numArgs == 2
        && (pythonToCpp[0] = Shiboken::Conversions::isPythonToCppConvertible(SbkPySide2_QtCoreTypeConverters[SBK_QSTRING_IDX], (pyArgs[0])))
        && (pythonToCpp[1] = Shiboken::Conversions::isPythonToCppConvertible(SbkPySide2_QtCoreTypeConverters[SBK_QSTRING_IDX], (pyArgs[1])))) {
        overloadId = 0; // functionRenamed(QString,QString)
    }

    // Function signature not found.
    if (overloadId == -1) goto Sbk_CutterCoreFunc_functionRenamed_TypeError;

    // Call function/method
    {
        ::QString cppArg0;
        pythonToCpp[0](pyArgs[0], &cppArg0);
        ::QString cppArg1;
        pythonToCpp[1](pyArgs[1], &cppArg1);

        if (!PyErr_Occurred()) {
            // functionRenamed(QString,QString)
            PyThreadState* _save = PyEval_SaveThread(); // Py_BEGIN_ALLOW_THREADS
            cppSelf->functionRenamed(cppArg0, cppArg1);
            PyEval_RestoreThread(_save); // Py_END_ALLOW_THREADS
        }
    }

    if (PyErr_Occurred()) {
        return {};
    }
    Py_RETURN_NONE;

    Sbk_CutterCoreFunc_functionRenamed_TypeError:
        Shiboken::setErrorAboutWrongArguments(args, "CutterBindings.CutterCore.functionRenamed");
        return {};
}

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:

def print_renamed(old, new):
    print('Function %s renamed!' % old)

core = CutterBindings.CutterCore.instance()
core.functionRenamed.connect(print_renamed)

I would expect the type of functionRenamed to be the same as say a push button clicked signal

core = CutterBindings.CutterCore.instance()
button = QtWidgets.QPushButton('Hello')
 
print(type(button.clicked))
print(type(core.functionRenamed))

Additional 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.

  • 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:

https://blog.basyskom.com/2019/using-shiboken2-to-create-python-bindings-for-a-qt-library/

@xarkes
Copy link
Member

xarkes commented Apr 22, 2019

Thanks for the report, cc @thestr4ng3r

@Maijin Maijin added the BUG label Apr 28, 2019
@thestr4ng3r
Copy link
Member

Actually it is possible to connect to CutterCore's signals like this:

QObject.connect(cutter.core(), SIGNAL("seekChanged(RVA)"), self.update_contents)

but yeah the way these are generated as functions is still wrong and should be fixed.

@gaasedelen
Copy link
Author

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants