Installing pyqtSignal via class builder

61 views
Skip to first unread message

Marcus Ottosson

unread,
Oct 8, 2013, 9:39:59 AM10/8/13
to python_in...@googlegroups.com
I'm building widgets via a separate builder method and would like them all to get the same set of signals. So I tried

from PyQt4.QtGui import *
from PyQt4.QtCore import *

if __name__ == '__main__':
import sys

app = QApplication(sys.argv)

widget = QLineEdit()
widget.mysignal = pyqtSignal(object)
widget.mysignal.connect(widget.textChanged)

widget.show()

sys.exit(app.exec_())


But I'm getting:

AttributeError: 'PyQt4.QtCore.pyqtSignal' object has no attribute 'connect'

So I suspect it may have something to do with pyqtSignal being a factory and that it may introspect the class in which it is usually called (to get it's name) but can't wrap my head around how to make it work in a builder, or to simply assign a signal to an object outside of it's constructor.

Anyone encountered this? How would you rather solve this issue? Ultimately, I'm looking to avoid typing the 4-5 separate signals that I'd like all of my similar widgets to inherit. Is multiple inheritance a better way?

Justin Israel

unread,
Oct 8, 2013, 4:21:04 PM10/8/13
to python_in...@googlegroups.com
You are right that you can't just assign a pyqtSignal to an instance. It has to be a class attribute so that the metaclass can create the proper plumbing under the hood. Though i am not exactly sure what you need without seeing a bit more of the examples. Are they always QLineEdit widgets and is connecting the signal part of your builder?
Multiple inheritance will solve the part about getting the signals onto the objects, but not really solving the connections if they are all different types.



--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOAuoev5qiHJn-h%3DeXQWbqAs%3DfZzjpVOFTT8SdbpCxyUCw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Marcus Ottosson

unread,
Oct 10, 2013, 3:41:46 PM10/10/13
to python_in...@googlegroups.com
Thanks for your respose, Justin.

The point of this little excersize was to give a few different types of widgets, QLineEdit and QTextEdit amongst others an identical interface when it comes to signalling that they have changed.

Ideally, they would all say "changed" when they have changed, but I've found there to be some inconsistencies that I'm usually working around from outside of the widget. Such as QLineEdit sigalling textChanged and a QCheckBox signalling something else.

I'm essentially using them in an identical fashion and are looking for ways in which I coud better unify their interfaces, if that makes sense. Perhaps a builder is not the way to go, although it has worked rather successfully for other parts, such as assembling a few different widgets into a composite widget.

The plumbing under the hood that you speak of, do you think it could be done manually and perhaps that way be used via a builder?

Justin Israel

unread,
Oct 11, 2013, 4:41:03 AM10/11/13
to python_in...@googlegroups.com
I am not sure it is something you can set up on an existing instance.  You are probably better off subclassing and using a mixin approach.
Again I am not sure what your usage looks like, but I have some thing I called a "VariableWidget" where I expose a setValue() and getValue() and depending on the type of value provided, I swap in different widget representations, but they all get routed up to the same common top level signals like "valueChanged". 



Marcus Ottosson

unread,
Oct 11, 2013, 8:29:44 AM10/11/13
to python_in...@googlegroups.com
Ah, you're putting the problem on its head. I'll have to give that a go, seems like it might suit quite well.

As for a use case, I'm having a widget, say Editor, take an arbitrary datastructure, like a plain text document, markdown formatted document, a dict or list, a database table and so on, and display an appropriate View for each, such as QTextEdit or QTreeView. They all link up to the main window, such as documentChanged that the window doesn't have to think about what editor is being used.


Justin Israel

unread,
Oct 11, 2013, 3:08:12 PM10/11/13
to python_in...@googlegroups.com

Ya that sounds exactly like what I have except mine only displays simpler types. Like:

List/set - qcombobox
Str  - qlineedit
Bool - qcheckbox
Int - qspinbox
Float - qdoublespinbox
None - qlabel fixed to "N/A"

It uses a qstackedlayout and lazy initializes the matching widget when the value is set, makes it the visible widget and wires its signals into the standard public ones.
Pretty useful in forms where the value could be multiple types and I don't have to think about it.

Reply all
Reply to author
Forward
0 new messages