![]() |
Home · Examples |
[Previous: Porting to Qt 4 - Drag and Drop][Porting Guides][Next: Porting to Graphics View]
Information about changes to the .ui file format in Qt 4. Qt Designer has changed significantly in the Qt 4 release. We have moved away from viewing Qt Designer as an IDE and concentrated on creating a robust form builder which can be extended and embedded in existing IDEs. Our efforts are ongoing and include the Visual Studio Integration, as well as integrating Designer with KDevelop and possibly other IDEs.
The most important changes in Qt Designer 4 which affect porting for .ui files are summarized below:
In Qt 4, uic creates a header file containing a POD class. The name of this class is the object name of the main container, qualified with the Ui namespace (e.g., Ui::MyForm). The class is implemented using inline functions, removing the need of a separate .cpp file. Just as in Qt 3, this class contains pointers to all the widgets inside the form as public members. In addition, the generated class provides the public method setupUi().
The class generated by uic is not a QWidget; in fact, it's not even a QObject. Instead, it is a class which knows how to populate an instance of a main container with the contents of the form. The programmer creates the main container himself, then passes it to setupUi().
For example, here's the uic output for a simple helloworld.ui form (some details were removed for simplicity):
namespace Ui { class HelloWorld { public: QVBoxLayout *vboxLayout; QPushButton *pushButton; void setupUi(QWidget *HelloWorld) { HelloWorld->setObjectName(QString::fromUtf8("HelloWorld")); vboxLayout = new QVBoxLayout(HelloWorld); vboxLayout->setObjectName(QString::fromUtf8("vboxLayout")); pushButton = new QPushButton(HelloWorld); pushButton->setObjectName(QString::fromUtf8("pushButton")); vboxLayout->addWidget(pushButton); retranslateUi(HelloWorld); } }; }In this case, the main container was specified to be a QWidget (or any subclass of QWidget). Had we started with a QMainWindow template in Qt Designer, setupUi()'s parameter would be of type QMainWindow.
There are two ways to create an instance of our form. One approach is to create an instance of the Ui::HelloWorld class, an instance of the main container (a plain QWidget), and call setupUi():
#include <QApplication> #include <QWidget> #include "ui_helloworld.h" // defines Ui::HelloWorld int main(int argc, char *argv[]) { QApplication app(argc, argv); QWidget w; Ui::HelloWorld ui; ui.setupUi(&w); w.show(); return app.exec(); }The second approach is to inherit from both the Ui::HelloWorld class and the main container, and to call setupUi() in the constructor of the subclass. In that case, QWidget (or one of its subclasses, e.g. QDialog) must appear first in the base class list so that moc picks it up correctly. For example:
#include <QApplication> #include <QWidget> #include "ui_helloworld.h" // defines Ui::HelloWorld class HelloWorldWidget : public QWidget, public Ui::HelloWorld { Q_OBJECT public: HelloWorldWidget(QWidget *parent = 0) : QWidget(parent) { setupUi(this); } }; int main(int argc, char *argv[]) { QApplication app(argc, argv); HelloWorldWidget w; w.show(); return app.exec(); }This second method is useful when porting Qt 3 forms to Qt 4. HelloWorldWidget is a class whose instance is the actual form and which contains public pointers to all the widgets in it. It therefore has an interface identical to that of a class generated by uic in Qt 3.
Creating POD classes from .ui files is more flexible and generic than the old approach of creating widgets. Qt Designer doesn't need to know anything about the main container apart from the base widget class it inherits. Indeed, Ui::HelloWorld can be used to populate any container that inherits QWidget. Conversely, all non-GUI aspects of the main container may be implemented by the programmer in the application's sources without reference to the form. The first method generates a Qt 3 style header and implementation which uses Qt 4 widgets (this includes the Qt 3 compatibility classes present in the Qt3Support library). This process should be familiar to anyone used to working with Qt Designer 3: Working with uic3
Qt 4 comes with the tool uic3 for working with old .ui files. It can be used in two ways:
You can use both these methods in combination to obtain .ui, header and source files that you can use as a starting point when porting your user interface to Qt 4.
uic3 myform.ui > myform.h
uic3 -impl myform.h myform.ui > myform.cpp
The resulting files myform.h and myform.cpp implement the form in Qt 4 using a QWidget that will include custom signals, slots and connections specified in the .ui file. However, see below for the limitations of this method.
The second method is to use uic3 to convert a Qt Designer 3 .ui file to the Qt Designer 4 format:
uic3 -convert myform3.ui > myform4.uiThe resulting file myform4.ui can be edited in Qt Designer 4. The header file for the form is generated by Qt 4's uic. See the Using a Component in Your Application chapter of the Qt Designer Manual for information about the preferred ways to use forms created with Qt Designer 4.
uic3 tries very hard to map Qt 3 classes and their properties to Qt 4. However, the behavior of some classes changed significantly in Qt 4. To keep the form working, some Qt 3 classes are mapped to classes in the Qt3Support library. Table 1 shows a list of classes this applies to.
QButtonGroup | Q3ButtonGroup |
QDateEdit | Q3DateEdit |
QDateTimeEdit | Q3DateTimeEdit |
QGroupBox | Q3GroupBox |
QListBox | Q3ListBox |
QListView | Q3ListView |
QMainWindow | Q3MainWindow |
QTextEdit | Q3TextEdit |
QTextView | Q3TextView |
QTimeEdit | Q3TimeEdit |
QWidgetStack | Q3WidgetStack |
QWizard | Q3Wizard |
class HelloWorldWidget : public QWidget, public Ui::HelloWorld { Q_OBJECT public: HelloWorldWidget(QWidget *parent = 0); public slots: void mySlot(); }; HelloWorldWidget::HelloWorldWidget(QWidget *parent) : QWidget(parent) { setupUi(this); QObject::connect(pushButton, SIGNAL(clicked()), this, SLOT(mySlot())); } void HelloWorldWidget::mySlot() { ... }A quick and dirty way to port forms containing custom signals and slots is to generate the code using uic3, rather than uic. Since uic3 does generate a QWidget, it will populate it with custom signals, slots and connections specified in the .ui file. However, uic3 can only generate code from Qt 3 .ui files, which implies that the .ui files never get translated and need to be edited using Qt Designer 3.
Note also that it is possible to create implicit connections between the widgets in a form and the main container. After setupUi() populates the main container with child widgets it scans the main container's list of slots for names with the form on_objectName_signalName().objectNamesignalName
If the form contains a widget whose object name is objectNameobjectName, and if that widget has a signal called signalNamesignalName, then this signal will be connected to the main container's slot. For example:
class HelloWorldWidget : public QWidget, public Ui::HelloWorld { Q_OBJECT public: HelloWorldWidget(QWidget *parent = 0); public slots: void on_pushButton_clicked(); }; HelloWorldWidget::HelloWorldWidget(QWidget *parent) : QWidget(parent) { setupUi(this); } void HelloWorldWidget::on_pushButton_clicked() { ... }Because of the naming convention, setupUi() automatically connects pushButton's clicked() signal to HelloWorldWidget's on_pushButton_clicked() slot.
Imagine that we have two icons, yes.png and no.png. We create a resource file called icons.qrc with the following contents:
<RCC version="1.0"> <qresource prefix="/icons"> <file>yes.png</file> <file>no.png</file> </qresource> </RCC>Next, we add the resource file to our .pro file:
RESOURCES += icons.qrcWhen qmake is run, it will create the appropriate Makefile rules to call rcc on the resource file, and compile and link the result into the application. The icons may be accessed as follows:
QFile file(":/icons/yes.png"); QIcon icon(":/icons/no.png"); QPixmap pixmap(":/icons/no.png");In each case, the leading colon tells Qt to look for the file in the virtual file tree defined by the set of resource files compiled into the application instead of the file system.
In the .qrc file, the qresource tag's prefix attribute is used to arrange the files into categories and set a virtual path where the files will be accessed.
Caveat: If the resource file was not linked directly into the application, but instead into a dynamic or static library that was later linked with the application, its virtual file tree will not be available to QFile and friends until the Q_INIT_RESOURCE() macro is called. This macro takes one argument, which is the name of the .qrc file, without the path or the file extension. A convenient place to initialize resources is at the top of the application's main() function.
In Qt Designer 4, we can associate any number of resource files with a form using the resource editor tool. The widgets in the form can access all icons specified in its associated resource files.
In short, porting of icons from a Qt 3 to a Qt 4 form involves the following steps:
uic3 -convert handles the conversion of custom widgets to the new .ui format, however all custom signals and slots are lost. Furthermore, since Qt Designer 3 never knew the base widget class of a custom widget, it is taken to be QWidget. This is often sufficient. If not, the custom widgets have to be inserted manually into the form.
Custom widget plugins, which contain custom widgets to be used in Qt Designer, must themselves be ported before they can be used in forms ported with uic3. The Porting to Qt 4 document contains information about general porting issues that may apply to the custom widget code itself, and the Creating Custom Widgets for Qt Designer chapter of the Qt Designer Manual describes how the ported widget should be built in order to work in Qt Designer 4.
Copyright © 2008 Nokia | Trademarks | Qt Jambi 4.4.3_01 |