[PyQt] QThread, Slots, Signals, meta type information error

[Giuseppe Corbelli]

On 3/4/19 5:09 PM, Repscher, Benedikt wrote:
> Thank you for your reply.
> I read the article "you're doing it wrong" and learned some things
> from it. However, it didn't help me resolve my issue.
> 
> I sort of resvoled the issue.
> I discovered the difference because the code that I actually use
> looks  a little bit different (uses 2 QThreads). However, this code raised the
> same error, even though it uses the moveTothread()-approach.
> 
> 
> Anyways...
> The code that I posted here that uses the moveToThread()-approach
> works, because the signal belongs to the same object as the slot.
> Therefore, Qt seems to use a Qt.DirectConnection (non-queued).
> However, when you want to use QueuedConnection (which is the default
> when usign the QThread-subclassing-approach) then the connection fails
> because of lacking meta-info.
> 
> Therefore, IMHO, the problem with missing meta-info still persists.
> The moveToThread()-approach just works around the issue, because it
> doesn't use the queued connection.
> 
> Consider the matter closed.

Well, not really :-)

I don't have a pyqt+btle installation but, strictly Qt speaking:
"A single QMetaObject instance is created for each QObject subclass that 
is used in an application [...]"
And QBluetoothDeviceInfo is not a QObject subclass.

AFAIK (little and less, admittedly) however your issue is related to the 
serialization that must be done to copy the object so that the target 
thread can have its own instance. In turn this means that QMetaType info 
should be available for the class, and in fact it is by looking at the 
Q_DECLARE_METATYPE(QBluetoothDeviceInfo) line in qbluetoothdeviceinfo.h

So basically I cannot be of much help, since everything seems to be in 
the right place.

Did you try the connection without the pyqtSlot decorator?

Out of curiosity: why are you explicitly calling the underlying 
thread().exec_() in a QObject moved to that thread?

-- 
Giuseppe Corbelli