2

So for the only way that I can see to create a style signal with PyQt4 is as follows:

class MyCustomClass(QtCore.QThread):
    custom_signal = QtCore.pyqtSignal(str)

My beef is if I declare that signal anywhere else, pyqt throws an error at me about how custom_signal doesn't have a connect() function.

I would like to create a helper function to help remove the boilerplate/repeated code when I want to do something as simple as: starting a new thread, doing work in that thread, sending the result as a signal to an object. But it's hard when I need the signals to be defined in a class.

Any way to have a signal just be a local variable?

Sandro
  • 2,219
  • 4
  • 27
  • 41
  • "But it's hard when I need the signals to be defined in a class." Why? – Junuxx Jun 26 '12 at 02:28
  • I can't define the type of the signal through the constructor. So that means that I need to have a collection of classes that handle every combination of different types of signals to send. – Sandro Jun 26 '12 at 03:49

1 Answers1

1

Not sure if I'm understanding your question correctly, but from your comment it sounds like it's sufficient to define a signal that will work for any type? If that's the case, you could use object as the type:

class MyCustomClass(QtCore.QThread):
    custom_signal = QtCore.pyqtSignal(object)

Simple test:

>>> def callback(result):
...    print type(result)
...
>>> obj = MyCustomClass()
>>> obj.custom_signal.connect(callback)
>>> obj.custom_signal.emit('hello')
<type 'str'>
>>> obj.custom_signal.emit({'x': 1})
<type 'dict'>
Ingrid
  • 160
  • 3
  • well this is embarrassing... Why not just use object for everything then? – Sandro Jun 26 '12 at 14:48
  • I think it's ok to use object in the (rare) cases when the type of parameter(s) doesn't matter. If only certain types are acceptable, you should probably define them explicitly as overloads, so that you can connect to the appropriate one and not have to do any type checking in your callbacks. – Ingrid Jun 26 '12 at 15:43