Designer question - probably obvious
I'm unclear how to get new views to show up in designer. I don't want designer to do anything interesting with my view - just allow me to place it and wire up the events and signals. All of those are declared, and my view is a subclass of QAbstractItemView. Naively, it seems to me that designer out to be able to handle that without any need for a view-specific plugin.
Do I need to build a plugin to get designer to work with my view? If not, how do I make designer aware that the new subclass of QAbstractItemView exists?
If there is an existing tutorial or documentation on this, a pointer would be fine - I suspect this is covered somewhere and I'm just not finding it.
mlong last edited by
Look in the documentation for "Widget Promotion".
winspear last edited by
I am not an expert but I guess only one of the following base GUI classes can be directly hooked up to QTDesigner.
Am i right ?
mlong: Widget promotion looks to provide part of what I'm after. What about making designer aware of the signals and slots in my class, though? When a widget is promoted, is the corresponding header file scanned for property declarations?
For non-container elements, it really looks to me as if everything returned in the QDesignerCustomWidgetInterface could equally well be stated by an XML file. The only interesting bit is "createWidget()", where the XML file would instead name a superclass known to Designer. Because of this, I'm a bit surprised that there is no way to simply add such an XML file to the project tree in some place that designer knows to look.
Eddy last edited by
You probably already looked at the Qt Designer manual "promoting page":http://doc.qt.nokia.com/4.7/designer-using-custom-widgets.html
AFAIK the signal and slots stuff is done in code but not accessible in Qt Designer when promoting. The basic idea is that you take an ancestor for your class (@winspear, other classes can be used. QFrame is popular in this case) , put it as a placeholder in your ui and promote it to your own class. After doing that you go into the code and handle signals and slots there. But not in Qt Designer.
If that is not what you want you will need to make a plugin. This page in "the manual":http://doc.qt.nokia.com/4.7/designer-creating-custom-widgets.html can be of interest then.
All of that makes sense, and it's the answer that I was expecting and/or afraid of. I was vaguely hopeful that Designer might do something about scanning the header file for signals, slots, and properties. I understand why that's not an easy thing to do, but the lack makes designer a good bit less useful than it might be. That said, designer is still evolving.
I looked at the plugin architecture a bit, and I was surprised about that as well. The model there is "one plugin type (i.e. C++ class) for each element type that you want to be able to manipulate in designer". That surprised me, since one can readily imagine (in abstract) a single plugin that handled multiple elements using a "one element type one plugin instance" sort of approach. More to the point, if a plugin could get some durable storage out of designer (like, say, the ability to store an XML tree describing the managed element), then a lot of freedom would open up.
At this point I'm talking about an architecture change in designer, and that's well beyond the scope of my original question. Where is the right place to discuss this sort of thing, if any?
Eddy last edited by
If you have specific wishes you can got to the "bug tracker also known as Jira.":https://bugreports.qt.nokia.com/secure/Dashboard.jspa
If you want to discuss your ideas, you could go to the irc channel on freenode.net where the Qt programmers are active. Channel #qt-creator.
andre last edited by
The designer plugin architecture is a bit different than what you seem to think it is. You can make a single-widget plugin, but you can also make multi-widget plugins. The class you are looking for in that case is [[doc:QDesignerCustomWidgetCollectionInterface]].