[Qt-interest] Exposing custom widget contents to qt designer

[Tony Rietwyk]

Hi Michael, 

AFAIK, the designer only stores properties declared on your custom widget
with STORED=true, which is the default for properties.  

Attached is a class that provides a check box with a text label that
internally sets the wrap property of the label to true.  When the designer
saves this widget to the ui file, in does NOT save any properties from the
child widgets.  It is up to your widget to set the properties of the
children itself, and provide its own properties, signals and slots to be
used by clients.  

Note: I (now) realise that this widget can probably be achieved via
overiding the paint on a normal QCheckBox override.  But understanding the
style code is so overwhelming, I don't have time to get my head around it!  

Hope that helps, 

Tony


> Sent: Saturday, 19 February 2011 06:45
> 
> Hi list,
> 
>      I'm using Qt 4.7.1, compiled from 
> qt-everywhere-opensource-src-4.7.1.tar.gz on 32 bit Fedora 14 with 
> configure options: -debug -developer-build -opensource -no-exceptions 
> -no-accessibility -no-qt3support -no-phonon -optimized-qmake -no-cups 
> -no-webkit
> 
>      I'm looking for some assistance on how to inform the qt 
> designer of 
> the internal configuration state of my custom widget. 
> Specifically, my 
> widget contains a qcombobox widget, and a qlabel. The purpose of the 
> widget is to interact with one of my company's products 
> through shared 
> memory, based on the contents of the qlabel and the qcombobox. The 
> widget works fully for all of our requirements except for its 
> behaviour 
> in qt designer.
> 
>      Currently, the contents of the qcombobox need to be stored 
> separately from the .ui file that we generate using the qt 
> designer, and 
> programmatically loaded and inserted into the combobox at the 
> widget's 
> creation.
> 
>      What we have observed, however is that when a qcombobox 
> is inserted 
> into the form, and the listwidgeteditor is used to insert new 
> items into 
> the combobox (the relevant function here is void 
> ComboBoxTaskMenu::editItems() in file 
> qt-everywhere-opensource-src-4.7.1/tools/designer/src/componen
> ts/taskmenu/combobox_taskmenu.cpp, 
> line 91 which calls various functions in the qcombobox itself 
> (Such as 
> void QComboBox::insertItem(int index, const QIcon &icon, 
> const QString 
> &text, const QVariant &userData), on line 2101 in 
> qt-everywhere-opensource-src-4.7.1/src/gui/widgets/qcombobox.c
> pp), then 
> the contents of the combobox widget are output to the .ui file, for 
> example:
> 
> <widget class="QComboBox" name="comboBox">
> <property name="geometry">
> <rect>
> <x>110</x>
> <y>230</y>
> <width>82</width>
> <height>25</height>
> </rect>
> </property>
> <item>
> <property name="text">
> <string>New Item1</string>
> </property>
> </item>
> <item>
> <property name="text">
> <string>New Item2</string>
> </property>
> </item>
> <item>
> <property name="text">
> <string>New Item3</string>
> </property>
> </item>
> </widget>
> 
>      When using, as a minimized psuedocode example, where 
> file points to 
> the .ui file:
> 
> QUiLoader loader;
> QWidget *screen = (loader.load(&file));
> 
>      The qcombobox is rebuilt with all of its designer-time contents 
> pre-loaded. I've built the appropriate task menu extensions for my 
> custom widget, and am able to insert items into the qcombobox that my 
> widget contains in the same way that the normal qcombobox has items 
> inserted, but none of the qcombobox information is being 
> stored into the 
> .ui file, and thus not being loaded by my QUILoader code. 
> Therefore, the 
> last piece of the puzzle is how the qcombobox communicates to the qt 
> designer what its contents are so that I can have my custom widget do 
> the same. I've identified 4 potential ways for this to 
> happen, and am in 
> the process of verifying or refuting each.
> 
>      Method A) The designer grabs a pointer/reference to some 
> qcombobox 
> internal object at the time that the qcombobox is added to 
> the form. The 
> qcombobox, as part of its normal operation, stores the appropriate 
> information into this internal object, and at save time the 
> qtdesigner 
> simply dumps that information to disk without needing to further 
> communicate with the qcombobox.
> 
>      Method B) The designer does a similar process, with the 
> difference 
> of grabbing a pointer/reference to this internal object at save time.
> 
>      Method C) The designer emits a signal to the widgets on 
> the form, 
> containing as an argument an object that the objects are expected to 
> dump their internal state into for writing to disk.
> 
>      Method D) the designer directly calls some function that 
> has as a 
> return value (or some kind of sideeffect) the information the 
> designer 
> needs to write out the ui file.
> 
>      I am fairly confident that method D does not happen. I've read a 
> large portion of the qcombobox source code, and don't see any 
> indication 
> that this is happening.
> 
>      I am also leaning towards saying that method B is not the case 
> either, for similar reasons.
> 
>      If method C is happening, I'm failing to find the slot that the 
> qcombobox uses to receive such a signal, but that is more of an 
> indication of me reading the wrong parts of the file than it 
> is that the 
> slot doesn't exist somewhere in the object hierarchy.
> 
>      Method A seems to be most likely to me, as the qcombobox has 
> functions to allow for returning the model of the qcombobox, 
> as well as 
> signals that indicate the model has been switched. Further, using the 
> task-menu extension to add items to the qcombobox causes interaction 
> with the model object in a way that leads me to believe that 
> the items 
> are ultimately stored inside of the model object.
> 
>       I've read through a pretty hefty chunk of 
> abstractformbuilder.cpp 
> and related classes, specifically the portions related to void 
> QAbstractFormBuilder::save(QIODevice *dev, QWidget *widget), 
> which makes 
> me think even more strongly that method A is the ticket here.
> 
>      Further, I've read the class documentation at: 
> http://doc.qt.nokia.com/4.7/qcombobox.html, 
> http://doc.qt.nokia.com/4.7/qwidget.html, 
> http://doc.qt.nokia.com/4.7/quiloader.html, and 
> http://doc.qt.nokia.com/latest/designer-taskmenuextension.html. The 
> custom widget tutorial indicates a way to store the state of 
> my combobox 
> as a multi-line string property, but that feels like the 
> wrong way to do 
> things. I already know that QT can save the state of the combobox 
> accurately and efficiently without relying on the properties 
> mechanism 
> (as evidenced by the entries being in "item" tags, and not "property" 
> tags) , and my team agrees that we'd like to avoid 
> reinventing the wheel 
> as much as possible.
> 
>      Any advice?
> 
> -- 
> Michael Jones
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: checkbox_wrap.h
Url: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110220/a27fa20c/attachment.h