The Evolution of Qt Designer
Материал из Wiki.crossplatform.ru
by Trenton Schulz
Qt Designer supplied with Qt 4.0 comprises many features that makes itthe fastest and easiest way to lay out and design forms. In this article,we'll take a look at the history of Qt Designer and some of the newfeatures and design decisions in Qt 4.0.
Содержание
[убрать]
Early GUI Builders
The Qt API has always made it easy to create a form. Using layoutmanagers, we can create forms relatively quickly. Still, thisapproach can rapidly become tedious if you have many forms to create.There's also the "edit, compile, run" cycle as you check thepositioning of widgets. During all of this you may start to thinkthat there really should be a GUI for making your GUI.
Already with Qt 1, there were a few GUI builders available as opensource software, with varying levels of layout and widget support.
- Qt Architect, developed by Jeff Harris and Klaus Ebner,allowed you to lay out the widgets, edit pixmaps for icons, and editcode for the forms. It was probably the most commonly used GUIbuilder for versions 1 and 2 of Qt.
- QtEZ, created by Sam Magnuson and later maintained by JanProkop, allowed you to develop most of your application withoutleaving the program. It could even generate a main()function for you.
- Ebuilder, by Ernie van der Meer, focused on theparent--child relationships of widgets and on building thesehierarchies.
Still, our users kept asking for a tool that was supported byTrolltech and that would always be synchronized with Qt releases.Also, early versions of these tools only offered manual placement forchild widgets, a major obstacle to cross-platform development.
The First Designer
Trolltech released Qt Designer 1.0 at the same time as Qt 2.2.From day one, dialogs created in Qt Designer were stored inwell-structured XML files (.ui files) that a separate tool, theUser Interface Compiler (uic), converted into C++ code. Qtapplications could also create forms based on .ui files atrun-time, using the QWidgetFactory class.
Qt Designer 1.0 also had the ability to define signals and slotsand to connect them together. The actual implementation of the slotswas done by subclassing the uic-generated classes andreimplementing the slots, which were declared virtual by uic. Thediagram below summarizes the situation.
The first version of Qt Designer also provided full support forhorizontal, vertical, and grid layouts. Qt developers could rapidlyadd child widgets to a form, snap them into a layout, and see howthey would behave when the user resized the dialog. This immediatefeedback cut out the "edit, compile, run" cycle of laying outwidgets.
It wasn't all rosy, though. Support for custom widgets was verylimited; they were rendered as a static image in the form, making ithard to tell how the actual form would behave without building it.Additionally, the subclassing technique was somewhat cumbersome (asthe diagram above illustrates) and required two classes, both withthe Q_OBJECT macro, resulting in needless overhead onQt/Embedded. Finally, Qt Designer 1.0 didn't support thecreation of main windows with menus and toolbars.
The Second Designer
Qt Designer 2.0 was released with Qt 3.0. It offered many featuresthat set it apart from the original Qt Designer. First, it alloweddevelopers to cut subclassing by using the .ui.h mechanism. The.ui.h file was included by the uic-generated source andallowed you to reimplement slots and even deal with construction anddestruction of the form.
A code editor was included inside of Qt Designer to edit the.ui.h file. Furthermore, there was a Source tab thatallowed you to add member variables, includes, and forwarddeclarations, in addition to signals and slots.
The second Qt Designer could also load several types of plugin.Widget plugins allowed you to create a plugin of your custom widget,making it possible to see the widget when using it on aform and access its properties. Another use of plugins was for wizards.It was even possible to connect to databases from insideQt Designer and view their data.
In addition, Qt Designer 2.0 included a .pro file parser,enabling you to manage your project from Qt Designer and to usethe built-in code editor to edit your source files. Some usersdeveloped entire applications using Qt Designer.
Making a Better Designer for Qt 4
Qt Designer was now an integral part of Qt, but there were stillthings that could be done to make it better. For instance, the codeeditor missed such features as being able to go to a specified line.There were also synchronization issues if you were editing a.ui.h file outside Qt Designer.
Another issue with Qt Designer was that it couldn't be integratedinto existing IDEs. This meant that developers who enjoyed theproductivity of IDEs had to leave it to use Qt Designer. Also,adding signals, slots, data members, declaration and implementationincludes, and more inside the Source tab was usuallyconsidered more troublesome than just editing the source filesdirectly.
All this and more lead to the work that would be part of the nextQt Designer. Many concepts needed to be revisited. As a result,an early glimpse of Qt Designer was part of the first Qt 4 beta. Asecond version containing a more complete feature set was introducedin beta 2 of Qt 4. The version contained in Qt 4's Release Candidateshould be almost identical to that in the final Qt 4 release. Let'stake a look at some of the features that are part of the new QtDesigner.
Better Integration with Existing IDEs |
Qt Designer has now been fully compartmentalized to make itpossible to integrate it with existing IDEs. This means that you cancreate a form, edit its properties with the property editor, doubleclick on a widget, and be taken to a slot that a widget's signalconnects to, all without leaving the IDE.
For Qt 4.0, a Visual Studio .NET integration is available. Workon integration with other IDEs, notably KDevelop and Eclipse, isplanned for later Qt 4 releases.
New File Generation Model |
Like before, Qt Designer still writes out .ui files thatcontain the specification of an interface, and uic generates C++code based on the .ui file. What has changed is that uic nowgenerates a simple struct containing all the widgets and asetupUi() function that creates the widgets and layouts. Thestruct does not inherit from QObject and is entirely definedin a header file.
There are three approaches to using a form in your application,reflecting the various ways in which standard C++ classes canbe combined together.
- In the direct approach, you simply construct a widget to use as aplaceholder for the component, and set up the user interface inside it. Forexample:
#include "ui_myform.h" // defines the Ui::MyForm struct
int main(int argc, char *argv[]) {
... QDialog dialog; Ui::MyForm ui; ui.setupUi(&dialog); dialog.show();...