<div dir="ltr"><div>PyQtGraph ran into this very issue a long time ago, but I don't think Qt C++ bindings allow for multiple inheritance of Qt objects.</div><div><br></div><div>For pyqtgraph, we created a inheritance chart diagram that might be helpful here, that demonstrates what objects inherit from what:</div><div><br></div><div><a href="https://pyqtgraph.readthedocs.io/en/latest/api_reference/uml_overview.html">https://pyqtgraph.readthedocs.io/en/latest/api_reference/uml_overview.html</a></div><div><br></div><div>For a lot of the functionality we needed, we created a class GraphicsItem(object):; and you can see the methods/docs/implementation here: <a href="https://pyqtgraph.readthedocs.io/en/latest/api_reference/graphicsItems/graphicsitem.html">https://pyqtgraph.readthedocs.io/en/latest/api_reference/graphicsItems/graphicsitem.html</a></div><div><br></div><div>We have a whole lot of "hasattr()" calls.</div><div><br></div><div>Ogi<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2024 at 7:00 AM <<a href="mailto:pyqt-request@riverbankcomputing.com">pyqt-request@riverbankcomputing.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send PyQt mailing list submissions to<br>
        <a href="mailto:pyqt@riverbankcomputing.com" target="_blank">pyqt@riverbankcomputing.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://www.riverbankcomputing.com/mailman/listinfo/pyqt" rel="noreferrer" target="_blank">https://www.riverbankcomputing.com/mailman/listinfo/pyqt</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:pyqt-request@riverbankcomputing.com" target="_blank">pyqt-request@riverbankcomputing.com</a><br>
<br>
You can reach the person managing the list at<br>
        <a href="mailto:pyqt-owner@riverbankcomputing.com" target="_blank">pyqt-owner@riverbankcomputing.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of PyQt digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Multiple inheritance for QGraphicsItem (Maurizio Berti)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 10 Jun 2024 05:39:54 +0200<br>
From: Maurizio Berti <<a href="mailto:maurizio.berti@gmail.com" target="_blank">maurizio.berti@gmail.com</a>><br>
To: pyqt <<a href="mailto:pyqt@riverbankcomputing.com" target="_blank">pyqt@riverbankcomputing.com</a>><br>
Subject: Multiple inheritance for QGraphicsItem<br>
Message-ID:<br>
        <CAPn+-XTeMW=<a href="mailto:BZbLYy1F8P3a857pO%2BW-amifL%2B9_AhbjxLE1uLw@mail.gmail.com" target="_blank">BZbLYy1F8P3a857pO+W-amifL+9_AhbjxLE1uLw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
As we all know, PyQt doesn't allow multiple inheritance of more Qt classes,<br>
except when explicitly allowed (eg. QTextObjectInterface).<br>
<br>
When using the Graphics View framework, though, it is sometimes useful to<br>
have a QGraphicsItem subclass that also provides QObject features: for<br>
example, a QGraphicsRectItem that emits a signal whenever its geometry<br>
changes.<br>
<br>
Right now, whenever I need something similar, I normally choose one of the<br>
following options, depending on my needs and code simplicity:<br>
<br>
- create a dummy QObject subclass and use an instance of it as a member of<br>
the actual QGraphicsItem one, then eventually emit its signals whenever<br>
necessary;<br>
- create a dummy QGraphicsObject subclass as the actual one to be used,<br>
with the "real" items as its children, then implementing boundingRect()<br>
(possibly returning childrenBoundingRect()) and a no-op paint(), and<br>
eventually "copying" the actual child item common functions by proper<br>
implementation, simple monkey patching or even __getattr__ override;<br>
<br>
While both solutions "work", they are not really acceptable, nor robust or<br>
reliable:<br>
<br>
- the dummy QObject "proxy" is an unnecessary difficulty that complicates<br>
access to the actual signal source; using Qt properties is a further<br>
complication (consider the case of using QPropertyAnimation);<br>
- the "main QGraphicsObject" approach adds complexity and further<br>
difficulties in geometry/transform management and access to the actually<br>
intended item;<br>
- issues with the lifespan of the QObject and the "real" QGraphicsItem,<br>
including connected signals (eg. using QTimers or animations);<br>
<br>
Qt actually considers and allows such multiple inheritance (it's the very<br>
nature of QGraphicsObject).<br>
<br>
So, my question is quite simple: would it be possible to allow proper<br>
multiple inheritance for QGraphicsItem+QObject?<br>
Therefore, would that implicitly allow multiple inheritance for all<br>
QGraphicsItem inherited classes (the standard ones and those created in<br>
Python, including mixins)?<br>
<br>
Thanks,<br>
MaurizioB<br>
<br>
-- <br>
? difficile avere una convinzione precisa quando si parla delle ragioni del<br>
cuore. - "Sostiene Pereira", Antonio Tabucchi<br>
<a href="http://www.jidesk.net" rel="noreferrer" target="_blank">http://www.jidesk.net</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20240610/d9f017d8/attachment-0001.htm" rel="noreferrer" target="_blank">https://www.riverbankcomputing.com/pipermail/pyqt/attachments/20240610/d9f017d8/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
PyQt mailing list<br>
<a href="mailto:PyQt@riverbankcomputing.com" target="_blank">PyQt@riverbankcomputing.com</a><br>
<a href="https://www.riverbankcomputing.com/mailman/listinfo/pyqt" rel="noreferrer" target="_blank">https://www.riverbankcomputing.com/mailman/listinfo/pyqt</a><br>
<br>
<br>
------------------------------<br>
<br>
End of PyQt Digest, Vol 239, Issue 10<br>
*************************************<br>
</blockquote></div>