Overriding method itemChange() not possible in Python for QAbstractGraphicsShapeItem derived classes

[mbarann]

Overriding method itemChange() ist not possible in Python for QAbstractGraphicsShapeItem derived classes, e.g. when sub classing QGraphicsRectItem.

This is caused by not including the itemChange() method in the generated code of class PythonQtShell_QGraphicsRectItem:
https://github.com/MeVisLab/pythonqt/blob/master/generated_cpp_511/com_trolltech_qt_gui/com_trolltech_qt_gui3.h#L457

Class PythonQtShell_QGraphicsPixmapItem, which does not derive from QAbstractGraphicsShapeItem, contains this method:
https://github.com/MeVisLab/pythonqt/blob/master/generated_cpp_511/com_trolltech_qt_gui/com_trolltech_qt_gui3.h#L110

After debugging the code generator, I found that the traversal of the base class hierarchy ignores the interface classes from which any super class inherits:
https://github.com/MeVisLab/pythonqt/blob/master/generator/abstractmetalang.cpp#L1632

[mbarann]

Here is a proposed patch to fix the code generation: patch.txt

[usiems]

I applied a fix that should consider really any interface class (in this context the secondary classes in multiple inheritance) in the inheritance chain.

[mbarann]

I applied a fix that should consider really any interface class (in this context the secondary classes in multiple inheritance) in the inheritance chain.

I had the same thought too. Additionally, I would also call super_class->fixFunctions() after super_class = super_class->baseClass() when traversing the hierarchy.

[florianlink]

I don’t think that would be necessary, fixFunctions is already called on all classes in a loop.

…

On Fri 28. Oct 2022 at 08:53, mbarann ***@***.***> wrote: I applied a fix that should consider really any interface class (in this context the secondary classes in multiple inheritance) in the inheritance chain. I had the same thought too. Additionally, I would also call super_class->fixFunctions() after super_class = super_class->baseClass() when traversing the hierarchy. — Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKHPHGKLEIELXO3BJBEE2DWFNZ7FANCNFSM6AAAAAARO55DZ4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mbarann]

I don’t think that would be necessary, fixFunctions is already called on
all classes in a loop.

I think it depends on the iteration order in the loop. If fixFunctions() is called on a derived_class before it is called on its base classes, then derived_class->fixFunctions() will iterate over the class hierarchy where all but the direct base class have not initialized there functions yet.

fixFunctions() calls super_class->queryFunctions() here, which only returns the functions if super_class->fixFunctions() was called before.
For the direct super_class, this is already ensured here.

[usiems]

Yeah, and the call to fix_functions calls fix_functions for the super_class recursively. Everything is as it should be.

[mbarann]

Right, I missed the recursive nature there.