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

[Michael Jones]

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/components/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.cpp), 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
Software Engineer
CyberMetrix
2860 N National Rd #A
Columbus, IN 47201- 4746 USA
812-375-5868