<div dir="ltr"><div>Hi Phil,</div><div>Ok, I see. It's a pity, but I understand your reasons.<br></div><div>At least, there are the options I listed in my first message, I just need to be careful in their implementation.</div><div><br></div><div>Thanks anyway.</div><div>Best regards,</div><div>MaurizioB<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 10 giu 2024 alle ore 16:45 Phil Thompson <<a href="mailto:phil@riverbankcomputing.com">phil@riverbankcomputing.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/06/2024 04:39, Maurizio Berti wrote:<br>
> As we all know, PyQt doesn't allow multiple inheritance of more Qt <br>
> classes,<br>
> except when explicitly allowed (eg. QTextObjectInterface).<br>
> <br>
> When using the Graphics View framework, though, it is sometimes useful <br>
> 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 <br>
> 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 <br>
> 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 <br>
> or<br>
> reliable:<br>
> <br>
> - the dummy QObject "proxy" is an unnecessary difficulty that <br>
> 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 <br>
> 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 <br>
> 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>
It's technically possible by creating a C++ class derived from QObject <br>
and QGraphicsRectItem and wrapping that (and the same for every other <br>
QGraphicsItem), but I'm not going to. I'm not going to start creating a <br>
higher-lever API above Qt.<br>
<br>
Phil<br>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">È difficile avere una convinzione precisa quando si parla delle ragioni del cuore. - "Sostiene Pereira", Antonio Tabucchi<br><a href="http://www.jidesk.net" target="_blank">http://www.jidesk.net</a></div>