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. On Oct 12, 2013 1:29 AM, "Marcus Ottosson" <[email protected]> wrote: > 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. > > > On 11 October 2013 09:41, Justin Israel <[email protected]> wrote: > >> 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". >> >> >> >> On Oct 11, 2013, at 8:41 AM, Marcus Ottosson wrote: >> >> 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? >> >> On Tuesday, 8 October 2013, Justin Israel wrote: >> >>> 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. >>> >>> >>> >>> On Wed, Oct 9, 2013 at 2:39 AM, Marcus Ottosson >>> <[email protected]>wrote: >>> >>>> 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? >>>> >>>> -- >>>> 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 [email protected]. >>>> 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. >>>> >>> >>> >>> -- >>> 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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA32B16N%2B7wPbEN%2BGA1A8eOstcaquxR9daW2m6uwXyWMog%40mail.gmail.com >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBzFX7g27UXvk6Wd1LSEntssMcyd5KAjfWns-JJLUPxJA%40mail.gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/63C5F469-BBCF-4B74-BA7B-C0491B003066%40gmail.com >> . >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODYaKFkyk7ZYKpeqpND8T1AocgsAHb7zwC8MSvCHASi8A%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA16BQ8JMD9zV%3DfcUH%3DxaxWgx0T9_zh5jMGrjKERR_8g7Q%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
