Getting to Know Qt Designer

Launching Designer The way that you launch Qt Designer depends on your platform: On Windows, click the Start button, under the Programs submenu, open the Qt 4 submenu and click Designer. On Unix or Linux, you might find a Qt Designer icon on the desktop background or in the desktop start menu under the Programming or Development submenus. You can launch Qt Designer from this icon. Alternatively, you can type designer in a terminal window. On Mac OS X, double click on Qt Designer in Finder.

The User Interface When used as a standalone application, Qt Designer's user interface can be configured to provide either a multi-window user interface (the default mode), or it can be used in docked window mode. When used from within an integrated development environment (IDE) only the multi-window user interface is available. You can switch modes in the Preferences dialog from the Edit menu. In multi-window mode, you can arrange each of the tool windows to suit your

working style. The main window consists of a menu bar, a tool bar, and a widget box that contains the widgets you can use to create your user interface. Qt Designer's Main Window The menu bar provides all the standard actions for managing forms, using the clipboard, and accessing application-specific help. The current editing mode, the tool windows, and the forms in use can also be accessed via the menu bar. The tool bar displays common actions that are used when editing a form. These are also available via the main menu. The widget box provides common widgets and layouts that are used to design components. These are grouped into categories that reflect their uses or features.

Most features of Qt Designer are accessible via the menu bar, the tool bar, or the widget box. Some features are also available through context menus that can be opened over the form windows. On most platforms, the right mouse is used to open context menus. Qt Designer's Widget Box The widget box provides a selection of standard Qt widgets, layouts, and other objects that can be used to create user interfaces on forms. Each of the categories in the widget box contain widgets with similar uses or related features. Note: Since Qt 4.4, new widgets have been included, e.g., QPlainTextEdit, QCommandLinkButton, QScrollArea, QMdiArea, and QWebView. You can display all of the available objects in a category by clicking on the handle next to the category label. When in Widget Editing Mode, you can add objects to a form by dragging the appropriate items from the widget box onto the form, and dropping them in the required locations.

Qt Designer provides a scratch pad feature that allows you to collect frequently used objects in a separate category. The scratch pad category can be filled with any widget currently displayed in a form by dragging them from the form and dropping them onto the widget box.

These widgets can be used in the same way as any other widgets, but they can also contain child widgets. Open a context menu over a widget to change its name or remove it from the scratch pad.

The Concept of Layouts in Qt A layout is used to arrange and manage the elements that make up a user interface. Qt provides a number of classes to automatically handle layouts -QHBoxLayout, QVBoxLayout, QGridLayout, and QFormLayout. These classes solve the challenge of laying out widgets automatically, providing a user interface that behaves predictably. Fortunately knowledge of the layout classes is not required to arrange widgets with Qt Designer. Instead, select one of the Lay Out Horizontally , Lay Out in a Grid , etc., options from the context menu. Each Qt widget has a recommended size, known as sizeHint(). The layout manager will attempt to resize a widget to meet its size hint. In some cases, there is no need to have a different size. For example, the height of a QLineEdit is always a fixed value, depending on font size and style. In other cases, you may require the size to change, e.g., the width of a QLineEdit or the width and height of item view widgets. This is where the widget size constraints -minimumSize and maximumSize constraints come into play. These are properties you can set in the property editor. For example, to override the default sizeHint(), simply set minimumSize and maximumSize to the same value. Alternatively, to use the current size as a size constraint value, choose one of the Size Constraint options from the widget's context menu. The layout will then ensure that those constraints are met. To control the size of your widgets via code, you can reimplement sizeHint() in your code. The screenshot below shows the breakdown of a basic user interface designed using a grid. The coordinates on the screenshot show the position of each widget within the grid.

Note: Inside the grid, the QPushButton objects are actually nested. The buttons on the right are first placed in a QVBoxLayout; the buttons at the bottom are first placed in a QHBoxLayout. Finally, they are put into coordinates (1,2) and (3,1) of the QGridLayout. To visualize, imagine the layout as a box that shrinks as much as possible, attempting to squeeze your widgets in a neat arrangement, and, at the same time, maximize the use of available space. Qt's layouts help when you: 1. Resize the user face to fit different window sizes. 2. Resize elements within the user interface to suit different localizations. 3. Arrange elements to adhere to layout guidelines for different platforms. So, you no longer have to worry about rearranging widgets for different platforms, settings, and languages. The example below shows how different localizations can affect the user interface. When a localization requires more space for longer text strings the Qt layout automatically scales to accommodate this, while ensuring that the user interface looks presentable and still matches the platform guidelines.

A Dialog in English

A Dialog in French

The process of laying out widgets consists of creating the layout hierarchy while setting as few widget size constraints as possible. For a more technical perspective on Qt's layout classes, refer to the Layout Management documentation. Qt Designer's Editing Modes

Qt Designer provides four editing modes: Widget Editing Mode, Signals and Slots Editing Mode, Buddy Editing Mode and Tab Order Editing Mode. When working with Qt Designer, you will always be in one of these four modes. To switch between modes, simply select it from the Edit menu or the toolbar. The table below describes these modes in further detail.
Editing Modes In Edit mode, we can change the appearance of the form, add layouts, and edit the properties of each widget. To switch to this mode, press F3. This is Qt Designer's default mode. In Signals and Slots mode, we can connect widgets together using Qt's signals and slots mechanism. To switch to this mode, press F4. In Buddy Editing Mode, buddy widgets can be assigned to label widgets to help them handle keyboard focus correctly. In Tab Order Editing Mode, we can set the order in which widgets receive the keyboard focus.

Using Layouts in Qt Designer Before a form can be used, the objects on the form need to be placed into layouts. This ensures that the objects will be displayed properly when the form is previewed or used in an application. Placing objects in a layout also ensures that they will be resized correctly when the form is resized.

Applying and Breaking Layouts The simplest way to manage objects is to apply a layout to a group of existing objects. This is achieved by selecting the objects that you need to manage and applying one of the standard layouts using the main toolbar, the Form menu, or the form's context menu. Once widgets have been inserted into a layout, it is not possible to move and resize them individually because the layout itself controls the geometry of each widget within it, taking account of the hints provided by spacers. Instead, you must either break the layout and adjust each object's geometry manually, or you can influence the widget's geometry by resizing the layout. To break the layout, press Ctrl+0 or choose Break Layout from the form's context menu, the Form menu or the main toolbar. You can also add and remove spacers from the layout to influence the geometries of the widgets. Inserting Objects into a Layout Objects can be inserted into an existing layout by dragging them from their current positions and dropping them at the required location. A blue cursor is displayed in the layout as an object is dragged over it to indicate where the object will be added.

Setting A Top Level Layout The form's top level layout can be set by clearing the slection (click the left mouse button on the form itself) and applying a layout. A top level layout is necessary to ensure that your widgets will resize correctly when its window is resized. To check if you have set a top level layout, preview your widget and attempt to resize the window by dragging the size grip. Applying a Layout To apply a layout, you can select your choice of layout from the toolbar shown on the left, or from the context menu shown below.

Horizontal and Vertical Layouts The simplest way to arrange objects on a form is to place them in a horizontal or vertical layout. Horizontal layouts ensure that the widgets within are aligned horizontally; vertical layouts ensure that they are aligned vertically. Horizontal and vertical layouts can be combined and nested to any depth. However, if you need more control over the placement of objects, consider using the grid layout. The Grid Layout Complex form layouts can be created by placing objects in a grid layout. This kind of layout gives the form designer much more freedom to arrange widgets on the form, but can result in a much less flexible layout. However, for some kinds of form layout, a grid arrangement is much more suitable than a nested arrangement of horizontal and vertical layouts. Splitter Layouts Another common way to manage the layout of objects on a form is to place them in a splitter. These splitters arrange the objects horizontally or vertically in the same way as normal layouts, but also allow the user to adjust the amount of space allocated to each object.

Although QSplitter is a container widget, Qt Designer treats splitter objects as layouts that are applied to existing widgets. To place a group of widgets into a splitter, select them as described here then apply the splitter layout by using the appropriate toolbar button, keyboard shortcut, or Lay out context menu entry. The Form Layout Since Qt 4.4, another layout class has been included -- QFormLayout. This class manages widgets in a two-column form; the left column holds labels and the right column holds field widgets such as line edits, spin boxes, etc. The QFormLayout class adheres to various platform look and feel guidelines and supports wrapping for long rows.

The UI file above results in the previews shown below. Windows XP Mac OS X Cleanlooks

Shortcut Keys In addition to the standard toolbar and context menu entries, there is also a set of keyboard shortcuts to apply layouts on widgets.

Layout Horizontal Vertical Grid Form Horizontal splitter Vertical splitter

Shortc ut

Description

Ctrl+1 Places the selected objects in a horizontal layout. Ctrl+2 Places the selected objects in a vertical layout. Ctrl+5 Places the selected objects in a grid layout. Ctrl+6 Places the selected objects in a form layout. Ctrl+3 Creates a horizontal splitter and places the selected objects inside it. Ctrl+4 Creates a vertical splitter and places the selected objects inside it.

Adjust size Ctrl+J Adjusts the size of the layout to ensure that each child object has sufficient space to display its contents. See QWidget::adjustSize() for more information. Note: Ctrl+0 is used to break a layout.

Qt Designer's Signals and Slots Editing Mode

In Qt Designer's signals and slots editing mode, you can connect objects in a form together using Qt's signals and slots mechanism. Both widgets and layouts can be connected via an intuitive connection interface, using the menu of compatible signals and slots provided by Qt Designer. When a form is saved, all connections are preserved so that they will be ready for use when your project is built. For more information on Qt's signals and sltos mechanism, refer to the Signals and Slots document. Connecting Objects To begin connecting objects, enter the signals and slots editing mode by opening the Edit menu and selecting Edit Signals/Slots, or by pressing the F4 key. All widgets and layouts on the form can be connected together. However, spacers just provide spacing hints to layouts, so they cannot be connected to other objects.

Highlighted Objects When the cursor is over an object that can be used in a connection, the object will be highlighted.

To make a connectionn, press the left mouse button and drag the cursor towards the object you want to connect it to. As you do this, a line will extend from the source object to the cursor. If the cursor is over another object on the form, the line will end with an arrow head that points to the destination object. This indicates that a connection will be made between the two objects when you release the mouse button. You can abandon the connection at any point while you are dragging the connection path by pressing Esc. Making a Connection The connection path will change its shape as the cursor moves around the form. As it passes over objects, they are highlighted, indicating that they can be used in a signal and slot connection. Release the mouse button to make the connection.

The Configure Connection dialog (below) is displayed, showing signals from the source object and slots from the destination object that you can use.

To complete the connection, select a signal from the source object and a slot from the destination object, then click OK. Click Cancel if you wish to abandon the connection. Note: If the Show all signals and slots checkbox is selected, all available signals from the source object will be shown. Otherwise, the signals and slots inherited from QWidget will be hidden. You can make as many connections as you like between objects on the form; it is possible to connect signals from objects to slots in the form itself. As a result, the signal and slot connections in many dialogs can be completely configured from within Qt Designer.

Connecting to a Form To connect an object to the form itself, simply position the cursor over the form and release the mouse button. The end point of the connection changes to the electrical "ground" symbol.

Editing and Deleting Connections By default, connection paths are created with two labels that show the signal and slot involved in the connection. These labels are usually oriented along the line of the connection. You can move them around inside their host widgets by dragging the red square at each end of the connection path. The Signal/Slot Editor The signal and slot used in a connection can be changed after it has been set up. When a connection is configured, it becomes visible in Qt Designer's signal and slot editor where it can be further edited. You can also edit signal/slot connections by double-clicking on the connection path or one of its labels to display the Connection Dialog.

Deleting Connections The whole connection can be selected by clicking on any of its path segments. Once selected, a connection can be deleted with the Delete key, ensuring that it will not be set up in the UI file.

Qt Designer's Buddy Editing Mode

One of the most useful basic features of Qt is the support for buddy widgets. A buddy widget accepts the input focus on behalf of a QLabel when the user types the label's shortcut key combination. The buddy concept is also used in Qt's model/view framework. Linking Labels to Buddy Widgets To enter buddy editing mode, open the Edit menu and select Edit Buddies. This mode presents the widgets on the form in a similar way to signals and slots editing mode but in this mode, connections must start at label widgets. Ideally, you should connect each label widget that provides a shortcut with a suitable input widget, such as a QLineEdit. Making Buddies To define a buddy widget for a label, click on the label, drag the connection to another widget on the form, and release the mouse button. The connection shown indicates how input focus is passed to the buddy widget. You can use the form preview to test the connections between each label and its buddy.

Removing Buddy Connections Only one buddy widget can be defined for each label. To change the buddy used, it is necessary to delete any existing buddy connection before you create a new one. Connections between labels and their buddy widgets can be deleted in the same way as signal-slot connections in signals and slots editing mode: Select the buddy connection by clicking on it and press the Delete key. This operation does not modify either the label or its buddy in any way. [Previous: Qt Designer's Signals and Slots Editing Mode] [Next: Qt Designer's Tab Order Editing Mode]

Qt Designer's Tab Order Editing Mode

Many users expect to be able to navigate between widgets and controls using only the keyboard. Qt lets the user navigate between input widgets with the Tab and Shift+Tab keyboard shortcuts. The default tab order is based on the order in which widgets are constructed. Although this order may be sufficient for many users, it is often better to explicitly specify the tab order to make your application easier to use. Setting the Tab Order To enter tab order editing mode, open the Edit menu and select Edit Tab Order. In this mode, each input widget in the form is shown with a number indicating its position in the tab order. So, if the user gives the first input widget the input focus and then presses the tab key, the focus will move to the second input widget, and so on. The tab order is defined by clicking on each of the numbers in the correct order. The first number you click will change to red, indicating the currently edited position in the tab order chain. The widget associated with the number will become the first one in the tab order chain. Clicking on another widget will make it the second in the tab order, and so on. Repeat this process until you are satisfied with the tab order in the form -you do not need to click every input widget if you see that the remaining widgets are already in the correct order. Numbers, for which you already set the order, change to green, while those which are not clicked yet, remain blue. If you make a mistake, simply double click outside of any number or choose Restart from the form's context menu to start again. If you have many widgets on your form and would like to change the tab order in the middle or at the end of the tab order chain, you can edit it at any position. Press Ctrl and click the number from which you want to start. Alternatively, choose Start from Here in the context menu.

Using Containers in Qt Designer Container widgets provide high level control over groups of objects on a form. They can be used to perform a variety of functions, such as managing input widgets, providing paged and tabbed layouts, or just acting as decorative containers for other objects.

Qt Designer provides visual feedback to help you place objects inside your

containers. When you drag an object from the widget box (or elsewhere) on the form, each container will be highlighted when the cursor is positioned over it. This indicates that you can drop the object inside, making it a child object of the container. This feedback is important because it is easy to place objects close to containers without actually placing them inside. Both widgets and spacers can be used inside containers. Stacked widgets, tab widgets, and toolboxes are handled specially in Qt Designer. Normally, when adding pages (tabs, pages, compartments) to these containers in your own code, you need to supply existing widgets, either as placeholders or containing child widgets. In Qt Designer, these are automatically created for you, so you can add child objects to each page straight away. Each container typically allows its child objects to be arranged in one or more layouts. The type of layout management provided depends on each container, although setting the layout is usually just a matter of selecting the container by clicking it, and applying a layout. The table below shows a list of available containers. Frames Frames are used to enclose and group widgets, as well as to provide decoration. They are used as the foundation for more complex containers, but they can also be used as placeholders in forms. The most important properties of frames are frameShape, frameShadow, lineWidth, and midLineWidth. These are described in more detail in the QFrame class description. Group Boxes Group boxes are usually used to group together collections of checkboxes and radio buttons with similar purposes. Among the significant properties of group boxes are title, flat, checkable, and checked. These are demonstrated in the Group Box example, and described in the QGroupBox class documentation. Each group box can contain its own layout, and this is necessary if it contains other widgets. To add a layout to the group box, click inside it and apply the layout as usual.

Stacked Widgets Stacked widgets are collections of widgets in which only the topmost layer is visible. Control over the visible layer is usually managed by another widget, such as combobox, using signals and slots.

Qt Designer shows arrows in the top-right corner of the stack to allow you to see all the widgets in the stack when designing it. These arrows do not appear in the preview or in the final component. To navigate between pages in the stack, select the stacked widget and use the Next Page and Previous Page entries from the context menu. The Insert Page and Delete Page context menu options allow you to add and remove pages.
Tab Widgets Tab widgets allow the developer to split up the contents of a widget into different labelled sections, only one of which is displayed at any given time. By default, the tab widget contains two tabs, and these can be deleted or renamed as required. You can also add additional tabs. To delete a tab: Click on its label to make it the current tab. Select the tab widget and open its context menu. Select Delete Page.

To add a new tab: Select the tab widget and open its context menu. Select Insert Page. You can add a page before or after the current page. Qt Designer will create a new widget for that particular tab and insert it into the tab widget. You can set the title of the current tab by changing the currentTabText property in the Property Editor .

ToolBox Widgets Toolbox widgets provide a series of pages or compartments in a toolbox. They are handled in a way similar to stacked widgets. To rename a page in a toolbox, make the toolbox your current pange and change its currentItemText property from the Property Editor. To add a new page, select Insert Page from the toolbox widget's context menu. You can add the page before or after the current page. To delete a page, select Delete Page from the toolbox widget's context menu. Dock Widgets Dock widgets are floating panels, often containing input widgets and more complex controls, that are either attached to the edges of the main window in "dock areas", or floated as independent tool windows. Although dock widgets can be added to any type of form, they are typically used with forms created from the main window template.

Creating Main Windows in Qt Designer

Qt Designer can be used to create user interfaces for different purposes, and it provides different kinds of form templates for each user interface. The main window template is used to create application windows with menu bars, toolbars, and dock widgets.
Create a new main window by opening the File menu and selecting the New Form... option, or by pressing Ctrl+N. Then, select the Main Window template. This template provides a main application window containing a menu bar and a toolbar by default -- these can be removed if they are not required. If you remove the menu bar, a new one can be created by selecting the Create Menu Bar option from the context menu, obtained by right-clicking within the main window form. An application can have only one menu bar, but several toolbars. Menus Menus are added to the menu bar by modifying the Type Here placeholders. One of

these is always present for editing purposes, and will not be displayed in the preview or in the finished window. Once created, the properties of a menu can be accessed using the Property Editor, and each menu can be accessed for this purpose via the The Object Inspector. Existing menus can be removed by opening a context menu over the label in the menu bar, and selecting Remove Menu 'menu_name' .

Creating a Menu Double-click the placeholder item to begin editing. The menu text, displayed using a line edit, can be modified. Insert the required text for the new menu. Inserting an ampersand character (&) causes the letter following it to be used as a mnemonic for the menu. Press Return or Enter to accept the new text, or press Escape to reject it. You can undo the editing operation later if required. Menus can also be rearranged in the menu bar simply by dragging and dropping them in the preferred location. A vertical red line indicates the position where the menu will be inserted. Menus can contain any number of entries and separators, and can be nested to the required depth. Adding new entries to menus can be achieved by navigating the menu structure in the usual way.

Creating a Menu Entry Double-click the Type Here placeholder to begin editing, or double-click Add Separator to insert a new separator line after the last entry in the menu. The menu entry's text is displayed using a line edit, and can be modified. Insert the required text for the new entry, optionally using the ampersand character (&) to mark the letter to use as a mnemonic for the entry. Press Return or Enter to accept the new text, or press Escape to reject it.

The action created for this menu entry will be accessible via the Action Editor, and any associated keyboard shortcut can be set there. Just like with menus, entries can be moved around simply by dragging and dropping them in the preferred location. When an entry is dragged over a closed menu, the menu will open to allow it to be inserted there. Since menu entries are based on actions, they can also be dropped onto toolbars, where they will be displayed as toolbar buttons. Toolbars

Creating and Removing a Toolbar Toolbars are added to a main window in a similar way to the menu bar: Select the Add Tool Bar option from the form's context menu. Alternatively, if there is an existing toolbar in the main window, you can click the arrow on its right end to create a new toolbar. Toolbars are removed from the form via an entry in the toolbar's context menu. Adding and Removing Toolbar Buttons Toolbar buttons are created as actions in the Action Editor and dragged onto the toolbar. Since actions can be represented by menu entries and toolbar buttons, they can be moved between menus and toolbars.

To share an action between a menu and a toolbar, drag its icon from the action editor to the toolbar rather than from the menu where its entry is located. See Adding an Action for more information about this process. Toolbar buttons are removed via the toolbar's context menu.

Actions With the menu bar and the toolbars in place, it's time to populate them with actions. New actions for both menus and toolbars are created in the action editor window, simplifying the creation and management of actions.

The Action Editor Enable the action editor by opening the Tools menu, and switching on the Action Editor option. The action editor allows you to create New actions and Delete actions. It also provides a search function, Filter, using the action's text.

Qt Designer's action editor can be viewed in the classic Icon View and Detailed View . The screenshot below shows the action editor in Detailed View. You can also copy and paste actions between menus, toolbars and forms.
Creating an Action To create an action, use the action editor's New button, which will then pop up an input dialog. Provide the new action with a Text -- this is the text that will appear in a menu entry and as the action's tooltip. The text is also automatically added to an "action" prefix, creating the action's Object Name. In addition, the dialog provides the option of selecting an Icon for the action, as well as removing the current icon. Once the action is created, it can be used wherever actions are applicable.

Adding an Action To add an action to a menu or a toolbar, simply press the left mouse button over the action in the action editor, and drag it to the preferred location.

Qt Designer provides highlighted guide lines that tell you where the action will be added. Release the mouse button to add the action when you have found the right spot.
Dock Widgets Since dock widgets are container widgets, they can be added to a form in the usuasl way. Once added to a form, dock widgets are not placed in any particular dock area by default; you need to set the docked property to true for each widget and choose an appropriate value for its dockWidgetArea property.

Adding a Dock Widget To add a dock widget to a form, drag one from the Containers section of the widget box, and drop it onto the main form area. Do not add the dock widget to an existing layout. Instead, open the Property Editor and enable the docked property to place it in a dock area. Note that it is sometimes easier to configure a dock widget if it is added to a form before a layout is applied to the central widget. For example, it is possible to undock it and resize it, making it more convenient to add child widgets. Dock widgets can be optionally floated as independent tool windows. Hence, it is useful to give them window titles by setting their windowTitle property. This also helps to identify them on the form.

Editing Resources with Qt Designer

Qt Designer fully supports the Qt Resource System, enabling resources to be specified together with forms as they are designed. To aid designers and developers manage resources for their applications, Qt Designer's resource editor allows resources to be defined on a per-form basis. In other words, each form can have a separate resource file.
Defining a Resource File To specify a resource file you must enable the resource editor by opening the Tools menu, and switching on the Resource Browser option. Resource Files Within the resource browser, you can open existing resource files or create new ones. Click the Edit Resources button to edit your resources. To reload resources, click on the Reload button .

Once a resource file is loaded, you can create or remove entries in it using the given Add Files and Remove Files buttons, and specify resources (e.g.,

images) using the Add Files button . Note that these resources must reside within the current resource file's directory or one of its subdirectories.

Editing Resource Files Press the button to add a new resource entry to the file. Then use the Add Files button to specify the resource. You can remove resources by selecting the correspondin g entry in the resource editor, and pressing the button.

Using the Resources Once the resources are defined you can use them actively when composing your form. For example, you might want to create a tool button using an icon specified in the resource file. Using Resources When changing properties with values that may be defined within a resource file, Qt Designer's property editor allows you to specify a resource in addition to the option of selecting a source file in the ordinary way.

Selecting a Resource You can open the resource selector by clicking Choose Resource... to add resources any time during the design process.

Using Stylesheets with Qt Designer Since Qt 4.2, it is possible to edit stylesheets in Qt Designer with the stylesheet editor.

Setting a Stylesheet The stylesheet editor can be accessed by right-clicking a widget and selecting Change styleSheet...

Using a Designer UI File in Your Application Qt Designer UI files represent the widget tree of the form in XML format. The forms can be processed:

 At compile time, which means that forms are converted to C++ code that can
be compiled. At runtime, which means that forms are processed by the QUiLoader class that dynamically constructs the widget tree while parsing the XML file.

Compile Time Form Processing You create user interface components with Qt Designer and use Qt's integrated build tools, qmake and uic, to generate code for them when the application is built. The generated code contains the form's user interface object. It is a C++ struct that contains: Pointers to the form's widgets, layouts, layout items, button groups, and actions. A member function called setupUi() to build the widget tree on the parent widget. A member function called retranslateUi() that handles the translation of the string properties of the form. For more information, see Reacting to Language Changes.

The generated code can be included in your application and used directly from it. Alternatively, you can use it to extend subclasses of standard widgets. A compile time processed form can be used in your application with one of the following approaches:

The Direct Approach: you construct a widget to use as a placeholder for

the component, and set up the user interface inside it. The Single Inheritance Approach: you subclass the form's base class (QWidget or QDialog, for example), and include a private instance of the form's user interface object. The Multiple Inheritance Approach: you subclass both the form's base class and the form's user interface object. This allows the widgets defined in the form to be used directly from within the scope of the subclass.

To demonstrate, we create a simple Calculator Form application. It is based on the original Calculator Form example. The application consists of one source file, main.cpp and a UI file. The calculatorform.ui file designed with Qt Designer is shown below:

We will use qmake to build the executable, so we need to write a .pro file: TEMPLATE FORMS SOURCES = app = calculatorform.ui = main.cpp

The special feature of this file is the FORMS declaration that tells qmake which files to process with uic. In this case, the calculatorform.ui file is used to create a ui_calculatorform.h file that can be used by any file listed in the SOURCES declaration. Note: You can use Qt Creator to create the Calculator Form project. It automatically generates the main.cpp, UI, and .pro files, which you can then modify.

The Direct Approach To use the direct approach, we include the ui_calculatorform.h file directly in main.cpp: #include "ui_calculatorform.h" The main function creates the calculator widget by constructing a standard QWidget that we use to host the user interface described by the calculatorform.ui file. int main(int argc, char *argv[]) { QApplication app(argc, argv); QWidget *widget = new QWidget; Ui::CalculatorForm ui; ui.setupUi(widget); widget->show(); return app.exec(); } In this case, the Ui::CalculatorForm is an interface description object from the ui_calculatorform.h file that sets up all the dialog's widgets and the connections between its signals and slots. The direct approach provides a quick and easy way to use simple, self-contained components in your applications. However, componens created with Qt Designer often require close integration with the rest of the application code. For instance, the CalculatorForm code provided above will compile and run, but the QSpinBox objects will not interact with the QLabel as we need a custom slot to carry out the add operation and display the result in the QLabel. To achieve this, we need to use the single inheritance approach. The Single Inheritance Approach To use the single inheritance approach, we subclass a standard Qt widget and include a private instance of the form's user interface object. This can take the form of: A member variable A pointer member variable

Using a Member Variable In this approach, we subclass a Qt widget and set up the user interface from within the constructor. Components used in this way expose the widgets and layouts used in the form to the Qt widget subclass, and provide a standard system for making signal and slot connections between the user interface and other objects in your application. The generated Ui::CalculatorForm structure is a member of the class. This approach is used in the Calculator Form example. To ensure that we can use the user interface, we need to include the header file that uic generates before referring to Ui::CalculatorForm: #include "ui_calculatorform.h" This means that the .pro file must be updated to include calculatorform.h: HEADERS = calculatorform.h

The subclass is defined in the following way: class CalculatorForm : public QWidget { Q_OBJECT public: CalculatorForm(QWidget *parent = 0); private slots: void on_inputSpinBox1_valueChanged(int value); void on_inputSpinBox2_valueChanged(int value); private: Ui::CalculatorForm ui; }; The important feature of the class is the private ui object which provides the code for setting up and managing the user interface. The constructor for the subclass constructs and configures all the widgets and layouts for the dialog just by calling the ui object's setupUi() function. Once this has been done, it is possible to modify the user interface as needed. CalculatorForm::CalculatorForm(QWidget *parent) : QWidget(parent) { ui.setupUi(this); } We can connect signals and slots in user interface widgets in the usual way, taking care to prefix the ui object to each widget used. The advantages of this approach are its simple use of inheritance to provide a QWidget-based interface, and its encapsulation of the user interface widget variables within the ui data member. We can use this method to define a number of user interfaces within the same widget, each of which is contained within its own namespace, and overlay (or compose) them. This approach can be used to create individual tabs from existing forms, for example. Using a Pointer Member Variable Alternatively, the Ui::CalculatorForm structure can be made a pointer member of the class. The header then looks as follows: namespace Ui { class CalculatorForm; } class CalculatorForm : public QWidget ... virtual ~CalculatorForm(); ... private: Ui::CalculatorForm *ui; ... The corresponding source file looks as follows: #include "ui_calculatorform.h"

CalculatorForm::CalculatorForm(QWidget *parent) : QWidget(parent), ui(new Ui::CalculatorForm) { ui->setupUi(this); } CalculatorForm::~CalculatorForm() { delete ui; } The advantage of this approach is that the user interface object can be forwarddeclared, which means that we do not have to include the generated ui_calculatorform.h file in the header. The form can then be changed without recompiling the dependent source files. This is particularly important if the class is subject to binary compatibility restrictions. We generally recommend this approach for libraries and large applications. For more information, see Creating Shared Libraries. The Multiple Inheritance Approach Forms created with Qt Designer can be subclassed together with a standard QWidget-based class. This approach makes all the user interface components defined in the form directly accessible within the scope of the subclass, and enables signal and slot connections to be made in the usual way with the connect() function. This approach is used in the Multiple Inheritance example. We need to include the header file that uic generates from the calculatorform.ui file, as follows: #include "ui_calculatorform.h" The class is defined in a similar way to the one used in the single inheritance approach, except that this time we inherit from both QWidget and Ui::CalculatorForm, as follows: class CalculatorForm : public QWidget, private Ui::CalculatorForm { Q_OBJECT public: CalculatorForm(QWidget *parent = 0); private slots: void on_inputSpinBox1_valueChanged(int value); void on_inputSpinBox2_valueChanged(int value); }; We inherit Ui::CalculatorForm privately to ensure that the user interface objects are private in our subclass. We can also inherit it with the public or protected keywords in the same way that we could have made ui public or protected in the previous case. The constructor for the subclass performs many of the same tasks as the constructor used in the single inheritance example: CalculatorForm::CalculatorForm(QWidget *parent) : QWidget(parent)

{ } In this case, the widgets used in the user interface can be accessed in the same say as a widget created in code by hand. We no longer require the ui prefix to access them. Reacting to Language Changes Qt notifies applications if the user interface language changes by sending an event of the type QEvent::LanguageChange. To call the member function retranslateUi() of the user interface object, we reimplement QWidget::changeEvent() in the form class, as follows: void CalculatorForm::changeEvent(QEvent *e) { QWidget::changeEvent(e); switch (e->type()) { case QEvent::LanguageChange: ui->retranslateUi(this); break; default: break; } } setupUi(this);

Run Time Form Processing Alternatively, forms can be processed at run time, producing dynamicallygenerated user interfaces. This can be done using the QtUiTools module that provides the QUiLoader class to handle forms created with Qt Designer. The UiTools Approach A resource file containing a UI file is required to process forms at run time. Also, the application needs to be configured to use the QtUiTools module. This is done by including the following declaration in a qmake project file, ensuring that the application is compiled and linked appropriately. CONFIG += uitools The QUiLoader class provides a form loader object to construct the user interface. This user interface can be retrieved from any QIODevice, e.g., a QFile object, to obtain a form stored in a project's resource file. The QUiLoader::load() function constructs the form widget using the user interface description contained in the file. The QtUiTools module classes can be included using the following directive: #include <QtUiTools> The QUiLoader::load() function is invoked as shown in this code from the Text Finder example: QWidget* TextFinder::loadUiFile() { QUiLoader loader; QFile file(":/forms/textfinder.ui");

file.open(QFile::ReadOnly); QWidget *formWidget = loader.load(&file, this); file.close(); } In a class that uses QtUiTools to build its user interface at run time, we can locate objects in the form using qFindChild(). For example, in the follownig code, we locate some components based on their object names and widget types: ui_findButton = qFindChild<QPushButton*>(this, "findButton"); ui_textEdit = qFindChild<QTextEdit*>(this, "textEdit"); ui_lineEdit = qFindChild<QLineEdit*>(this, "lineEdit"); Processing forms at run-time gives the developer the freedom to change a program's user interface, just by changing the UI file. This is useful when customizing programs to suit various user needs, such as extra large icons or a different colour scheme for accessibility support. Automatic Connections The signals and slots connections defined for compile time or run time forms can either be set up manually or automatically, using QMetaObject's ability to make connections between signals and suitably-named slots. Generally, in a QDialog, if we want to process the information entered by the user before accepting it, we need to connect the clicked() signal from the OK button to a custom slot in our dialog. We will first show an example of the dialog in which the slot is connected by hand then compare it with a dialog that uses automatic connection. A Dialog Without Auto-Connect We define the dialog in the same way as before, but now include a slot in addition to the constructor: class ImageDialog : public QDialog, private Ui::ImageDialog { Q_OBJECT public: ImageDialog(QWidget *parent = 0); private slots: void checkValues(); }; The checkValues() slot will be used to validate the values provided by the user. In the dialog's constructor we set up the widgets as before, and connect the Cancel button's clicked() signal to the dialog's reject() slot. We also disable the autoDefault property in both buttons to ensure that the dialog does not interfere with the way that the line edit handles return key events: ImageDialog::ImageDialog(QWidget *parent) : QDialog(parent) { setupUi(this); return formWidget;

} We connect the OK button's clicked() signal to the dialog's checkValues() slot which we implement as follows: void ImageDialog::checkValues() { if (nameLineEdit->text().isEmpty()) (void) QMessageBox::information(this, tr("No Image Name"), tr("Please supply a name for the image."), QMessageBox::Cancel); else accept(); } This custom slot does the minimum necessary to ensure that the data entered by the user is valid - it only accepts the input if a name was given for the image. Widgets and Dialogs with Auto-Connect Although it is easy to implement a custom slot in the dialog and connect it in the constructor, we could instead use QMetaObject's auto-connection facilities to connect the OK button's clicked() signal to a slot in our subclass. uic automatically generates code in the dialog's setupUi() function to do this, so we only need to declare and implement a slot with a name that follows a standard convention: void on_<object name>_<signal name>(<signal parameters>); Using this convention, we can define and implement a slot that responds to mouse clicks on the OK button: class ImageDialog : public QDialog, private Ui::ImageDialog { Q_OBJECT public: ImageDialog(QWidget *parent = 0); private slots: void on_okButton_clicked(); }; Another example of automatic signal and slot connection would be the Text Finder with its on_findButton_clicked() slot. We use QMetaObject's system to enable signal and slot connections: QMetaObject::connectSlotsByName(this); This enables us to implement the slot, as shown below: void TextFinder::on_findButton_clicked() { QString searchString = ui_lineEdit->text(); QTextDocument *document = ui_textEdit->document();

okButton->setAutoDefault(false); cancelButton->setAutoDefault(false); ... connect(okButton, SIGNAL(clicked()), this, SLOT(checkValues()));

bool found = false; if (isFirstTime == false) document->undo(); if (searchString.isEmpty()) { QMessageBox::information(this, tr("Empty Search Field"), "The search field is empty. Please enter a word and click Find."); } else { QTextCursor highlightCursor(document); QTextCursor cursor(document); ... cursor.endEditBlock(); isFirstTime = false; if (found == false) { QMessageBox::information(this, tr("Word Not Found"), "Sorry, the word cannot be found."); } } Automatic connection of signals and slots provides both a standard naming convention and an explicit interface for widget designers to work to. By providing source code that implements a given interface, user interface designers can check that their designs actually work without having to write code themselves. } cursor.beginEditBlock();

Using Custom Widgets with Qt Designer

Qt Designer can display custom widgets through its extensible plugin mechanism, allowing the range of designable widgets to be extended by the user and third parties. This feature also allows Qt Designer to optionally support Qt 3 compatibility widgets. Alternatively, it is possible to use existing widgets as placeholders for widget classes that provide similar APIs.
Widgets from the Qt3Support library are made available via in Qt Designer's support for custom widgets. Handling Custom Widgets Although Qt Designer supports all of the standard Qt widgets, and can be configured to handle widgets supplied in the Qt3Support library, some specialized widgets may not be available as standard for a number of reasons: Custom widgets may not be available at the time the user interface is being designed. Custom widgets may be platform-specific, and designers may be developing the user interface on a different platform to end users. The source code for a custom widget is not available, or the user interface designers are unable to use the widget for non-technical reasons.

In the above situations, it is still possible to design forms with the aim of

using custom widgets in the application. To achieve this, we can use the widget promotion feature of Qt Designer. In all other cases, where the source code to the custom widgets is available, we can adapt the custom widget for use with Qt Designer. Promoting Widgets

If some forms must be designed, but certain custom widgets are unavailble to the designer, we can substitute similar widgets to represent the missing widgets. For example, we might represent instances of a custom push button class, MyPushButton, with instances of QPushButton and promote these to MyPushButton so that uic generates suitable code for this missing class. When choosing a widget to use as a placeholder, it is useful to compare the API of the missing widget with those of standard Qt widgets. For specialized widgets that subclass standard classes, the obvious choice of placeholder is the base class of the custom widget; for example, QSlider might be used for specialized QSlider subclasses. For specialized widgets that do not share a common API with standard Qt widgets, it is worth considering adapting a custom widget for use in Qt Designer. If this is not possible then QWidget is the obvious choice for a placeholder widget since it is the lowest common denominator for all widgets. To add a placeholder, select an object of a suitable base class and choose Promote to ... from the form's context menu. After entering the class name and header file in the lower part of the dialog, choose Add. The placeholder class will now appear along with the base class in the upper list. Click the Promote button to accept this choice. Now, when the form's context menu is opened over objects of the base class, the placeholder class will appear in the Promote to submenu, allowing for convenient promotion of objects to that class. A promoted widget can be reverted to its base class by choosing Demote to from the form's context menu. User Defined Custom Widgets

Custom widgets can be adapted for use with Qt Designer, giving designers the opportunity to configure the user interface using the actual widgets that will be used in an application rather than placeholder widgets. The process of creating a custom widget plugin is described in the Creating Custom Widgets for Qt Designer chapter of this manual. To use a plugin created in this way, it is necessary to ensure that the plugin

is located on a path that Qt Designer searches for plugins. Generally, plugins stored in $QTDIR/plugins/designer will be loaded when Qt Designer starts. Further information on building and installing plugins can be found here. You can also refer to the Plugins HOWTO document for information about creating plugins.

Creating Custom Widgets for Qt Designer

Qt Designer's plugin-based architecture allows user-defined and third party custom widgets to be edited just like you do with standard Qt widgets. All of the custom widget's features are made available to Qt Designer, including widget properties, signals, and slots. Since Qt Designer uses real widgets during the form design process, custom widgets will appear the same as they do when previewed.

The QtDesigner module provides you with the ability to create custom widgets in Qt Designer. Getting Started To integrate a custom widget with Qt Designer, you require a suitable description for the widget and an appropriate .pro file. Providing an Interface Description To inform Qt Designer about the type of widget you want to provide, create a subclass of QDesignerCustomWidgetInterface that describes the various properties your widget exposes. Most of these are supplied by functions that are pure virtual in the base class, because only the author of the plugin can provide this information. Function name() group() toolTip() whatsThis() includeFile() Description of the return value The name of the class that provides the widget. The group in Qt Designer's widget box that the widget belongs to. A short description to help users identify the widget in Qt Designer. A longer description of the widget for users of Qt Designer. The header file that must be included in applications that use this widget. This information is stored in UI files and will be used by uic to create a suitable #includes statement in the code it generates for the form containing the custom widget. An icon that can be used to represent the widget in Qt Designer's widget box. True if the widget will be used to hold child widgets; false otherwise. A QWidget pointer to an instance of the custom widget, constructed with the parent supplied. Note: createWidget() is a factory function responsible for creating the widget only. The custom widget's properties will not be available until load() returns. A description of the widget's properties, such as its object

icon() isContainer() createWidget()

domXml()

Function

Description of the return value name, size hint, and other standard QWidget properties.

codeTemplate() This function is reserved for future use by Qt Designer. Two other virtual functions can also be reimplemented: initialize() Sets up extensions and other features for custom widgets. Custom container extensions (see QDesignerContainerExtension) and task menu extensions (see QDesignerTaskMenuExtension) should be set up in this function. Returns true if the widget has been initialized; returns false otherwise. Reimplementations usually check whether the initialize() function has been called and return the result of this test.

isInitialized()

Notes on the domXml() Function The domXml() function returns a UI file snippet that is used by Qt Designer's widget factory to create a custom widget and its applicable properties. Since Qt 4.4, Qt Designer's widget box allows for a complete UI file to describe one custom widget. The UI file can be loaded using the <ui> tag. Specifying the <ui> tag allows for adding the <customwidget> element that contains additional information for custom widgets. The <widget> tag is sufficient if no additional information is required If the custom widget does not provide a reasonable size hint, it is necessary to specify a default geometry in the string returned by the domXml() function in your subclass. For example, the AnalogClockPlugin provided by the Custom Widget Plugin example, defines a default widgetgeometry in the following way: ... " " " " " " " " ... An additional feature of the domXml() function is that, if it returns an empty string, the widget will not be installed in Qt Designer's widget box. However, it can still be used by other widgets in the form. This feature is used to hide widgets that should not be explicitly created by the user, but are required by other widgets. A complete custom widget specification looks like: <ui language="c++"> displayname="MyWidget"> <widget class="widgets::MyWidget" name="mywidget"/> <customwidgets> <customwidget> <class>widgets::MyWidget</class> <addpagemethod>addPage</addpagemethod> <propertyspecifications> <stringpropertyspecification name="fileName" notr="true" type="singleline" <stringpropertyspecification name="text" type="richtext" </propertyspecifications> <property name=\"geometry\">\n" <rect>\n" <x>0</x>\n" <y>0</y>\n" <width>100</width>\n" <height>100</height>\n" </rect>\n" </property>\n"

</customwidget> </customwidgets> </ui> Attributes of the <ui> tag: Attribute language Presen ce Values Comment This attribute specifies the language the custom widget is intended for. It is mainly there to prevent C++-plugins from appearing in Qt Jambi.

optiona "c++", l "jambi"

The value of the attribute appears in the Widget box and can be used to strip away namespaces. The <addpagemethod> tag tells Qt Designer and uic which method should be used to add pages to a container widget. This applies to container widgets that require calling a particular method to add a child rather than adding the child by passing the parent. In particular, this is relevant for containers that are not a a subclass of the containers provided in Qt Designer, but are based on the notion of Current Page. In addition, you need to provide a container extension for them. The <propertyspecifications> element can contain a list of property meta information. Currently, properties of type string are supported. For these properties, the <stringpropertyspecification> tag can be used. This tag has the following attributes: Attribu Presen te ce name type notr Values Comment

displayname

optiona Class l name

require Name of the d property require See below d table The value of the attribute determines how the property editor will handle them.

optiona "true", If the attribute is "true", the value is not l "false" meant to be translated. Values of the type attribute of the string property: Value "richtext" "multiline" "singleline" "stylesheet" "objectname" "url" Rich text. Multi-line plain text. Single-line plain text. A CSS-style sheet. An object name (restricted set of valid characters). URL, file name. Type

Plugin Requirements In order for plugins to work correctly on all platforms, you need to ensure that they export the symbols needed by Qt Designer. First of all, the plugin class must be exported in order for the plugin to be loaded by Qt Designer. Use the Q_EXPORT_PLUGIN2() macro to do this. Also, the QDESIGNER_WIDGET_EXPORT macro must be used to define each custom widget class within a plugin, that Qt Designer will instantiate.

Creating Well Behaved Widgets Some custom widgets have special user interface features that may make them behave differently to many of the standard widgets found in Qt Designer. Specifically, if a custom widget grabs the keyboard as a result of a call to QWidget::grabKeyboard(), the operation of Qt Designer will be affected. To give custom widgets special behavior in Qt Designer, provide an implementation of the initialize() function to configure the widget construction process for Qt Designer specific behavior. This function will be called for the first time before any calls to createWidget() and could perhaps set an internal flag that can be tested later when Qt Designer calls the plugin's createWidget() function. Building and Installing the Plugin A Simple Plugin The Custom Widget Plugin Example demonstrates a simple Qt Designer plugin. The .pro file for a plugin must specify the headers and sources for both the custom widget and the plugin interface. Typically, this file only has to specify that the plugin's project is to be built as a library, but with specific plugin support for Qt Designer. This is done with the following declarations: CONFIG TARGET TEMPLATE += designer plugin = $$qtLibraryTarget($$TARGET) = lib

If Qt is configured to build in both debug and release modes, Qt Designer will be built in release mode. When this occurs, it is necessary to ensure that plugins are also built in release mode. To do this, include the following declaration in the plugin's .pro file: CONFIG += release If plugins are built in a mode that is incompatible with Qt Designer, they will not be loaded and installed. For more information about plugins, see the Plugins HOWTO document. It is also necessary to ensure that the plugin is installed together with other Qt Designer widget plugins: target.path = $$[QT_INSTALL_PLUGINS]/designer INSTALLS += target The $[QT_INSTALL_PLUGINS] variable is a placeholder to the location of the installed Qt plugins. You can configure Qt Designer to look for plugins in other locations by setting the QT_PLUGIN_PATH environment variable before running the application. Note: Qt Designer will look for a designer subdirectory in each path supplied. See QCoreApplication::libraryPaths() for more information about customizing paths for libraries and plugins with Qt applications. Splitting up the Plugin In a real world scenario, you do not want to have dependencies of the application making use of the custom widgets to the Qt Designer headers and libraries as introduced by the simple approach explained above.

There are two ways to resolve this:

Create a .pri file that contains the headers sources and sources of the
custom widget: INCLUDEPATH += $$PWD HEADERS += $$PWD/analogclock.h SOURCES += $$PWD/analogclock.cpp This file would then be included by the .pro file of the plugin and the application: include(customwidget.pri) Running qmake -Wall on the .pro files causes a warning to be printed if an included .pri file cannot be found.

Create a standalone shared library containing the custom widgets only as

described in Creating Shared Libraries. This library would then be used by the application as well as by the Qt Designer plugin. Care must be taken to ensure that the plugin can locate the library at run-time. Related Examples For more information on using custom widgets in Qt Designer, refer to the Custom Widget Plugin and World Time Clock Plugin examples for more information about using custom widgets in Qt Designer. Also, you can use the QDesignerCustomWidgetCollectionInterface class to combine several custom widgets into a single library.

Creating Custom Widget Extensions Once you have a custom widget plugin for Qt Designer, you can provide it with the expected behavior and functionality within Qt Designer's workspace, using custom widget extensions. Extension Types There are several available types of extensions in Qt Designer. You can use all of these extensions in the same pattern, only replacing the respective extension base class. QDesignerContainerExtension is necessary when implementing a custom multi-page container. QDesignerTaskMenuExtension QDesignerTaskMenuExtension is useful for custom widgets. It provides an extension that allows you to add custom menu entries to Qt Designer's task menu. The Task Menu Extension example illustrates how to use this class.

QDesignerContainerExtension QDesignerContainerExtension is necessary when implementing a custom multi-page container. It provides an extension that allows you to add and delete pages for a multi-page container plugin in Qt Designer. The Container Extension example further explains how to use this class. Note: It is not possible to add custom per-page properties for some widgets (e.g., QTabWidget) due to the way they are implemented. QDesignerMemberSheetExtension The QDesignerMemberSheetExtension class allows you to manipulate a widget's member functions displayed when connecting signals and slots.

QDesignerPropertySheetExtension , QDesignerDynamicPropertySheetExtension These extension classes allow you to control how a widget's properties are displayed in Qt Designer's property editor.

Qt Designer uses the QDesignerPropertySheetExtension and the QDesignerMemberSheetExtension classes to feed its property and signal and slot editors. Whenever a widget is selected in its workspace, Qt Designer will query for the widget's property sheet extension; likewise, whenever a connection between two widgets is requested, Qt Designer will query for the widgets' member sheet extensions.
Warning: All widgets have default property and member sheets. If you implement custom property sheet or member sheet extensions, your custom extensions will override the default sheets. Creating an Extension To create an extension you must inherit both QObject and the appropriate base class, and reimplement its functions. Since we are implementing an interface, we must ensure that it is made known to the meta object system using the Q_INTERFACES() macro in the extension class's definition. For example: class MyExtension: public QObject, public QdesignerContainerExtension { Q_OBJECT Q_INTERFACE(QDesignerContainerExtension)

} This enables Qt Designer to use the qobject_cast() function to query for supported interfaces using a QObject pointer only. Exposing an Extension to Qt Designer In Qt Designer the extensions are not created until they are required. For this reason, when implementing extensions, you must subclass QExtensionFactory to create a class that is able to make instances of your extensions. Also, you must register your factory with Qt Designer's extension manager; the extension manager handles the construction of extensions. When an extension is requested, Qt Designer's extension manager will run through its registered factories calling QExtensionFactory::createExtension() for each of them until it finds one that is able to create the requested extension for the selected widget. This factory will then make an instance of the extension.

...

Creating an Extension Factory The QExtensionFactory class provides a standard extension factory, but it can also be used as an interface for custom extension factories. The purpose is to reimplement the QExtensionFactory::createExtension() function, making it able to create your extension, such as a MultiPageWidget container extension. You can either create a new QExtensionFactory and reimplement the QExtensionFactory::createExtension() function: QObject *ANewExtensionFactory::createExtension(QObject *object, const QString &iid, QObject *parent) const { if (iid != Q_TYPEID(QDesignerContainerExtension)) return 0; if (MyCustomWidget *widget = qobject_cast<MyCustomWidget*> (object)) return new MyContainerExtension(widget, parent); } or you can use an existing factory, expanding the QExtensionFactory::createExtension() function to enable the factory to create your custom extension as well: QObject *AGeneralExtensionFactory::createExtension(QObject *object, const QString &iid, QObject *parent) const { MyCustomWidget *widget = qobject_cast<MyCustomWidget*>(object); if (widget && (iid == Q_TYPEID(QDesignerTaskMenuExtension))) { return new MyTaskMenuExtension(widget, parent); } else if (widget && (iid == Q_TYPEID(QDesignerContainerExtension))) { return 0;

return new MyContainerExtension(widget, parent); } else { return 0; } }

Accessing Qt Designer's Extension Manager When implementing a custom widget plugin, you must subclass the QDesignerCustomWidgetInterface to expose your plugin to Qt Designer. This is covered in more detail in the Creating Custom Widgets for Qt Designer section. The registration of an extension factory is typically made in the QDesignerCustomWidgetInterface::initialize() function: void MyPlugin::initialize(QDesignerFormEditorInterface *formEditor) { if (initialized) return; QExtensionManager *manager = formEditor->extensionManager(); Q_ASSERT(manager != 0); manager->registerExtensions(new MyExtensionFactory(manager), Q_TYPEID(QDesignerTaskMenuExtension)); } The formEditor parameter in the QDesignerCustomWidgetInterface::initialize() function is a pointer to Qt Designer's current QDesignerFormEditorInterface object. You must use the QDesignerFormEditorInterface::extensionManager() function to retrieve an interface to Qt Designer's extension manager. Then you use the QExtensionManager::registerExtensions() function to register your custom extension factory. Related Examples For more information on creating custom widget extensions in Qt Designer, refer to the Task Menu Extension and Container Extension examples. initialized = true;

Qt Designer's UI File Format The UI file format used by Qt Designer is described by the XML schema presented below, which we include for your convenience. Be aware that the format may change in future Qt releases. <?xml version="1.0" encoding="utf-8" ?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="ui" type="UI"/> <xs:complexType name="UI"> <xs:all> <xs:element name="author" type="xs:string" minOccurs="0" /> <xs:element name="comment" type="xs:string"

minOccurs="0" /> minOccurs="0" /> <xs:element name="class" type="xs:string" /> <xs:element name="widget" type="Widget" /> <xs:element name="layoutdefault" type="LayoutDefault" minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> </xs:all> <xs:attribute name="version" type="xs:string" use="required" /> <xs:attribute name="language" type="xs:string" /> <xs:attribute name="displayname" type="xs:string" /> <!-- Legacy attribute generated by uic3 --> <xs:attribute name="stdsetdef" type="xs:integer" /> <!-- Legacy attribute generated by the VS integration --> <xs:attribute name="stdSetDef" type="xs:integer" /> </xs:complexType> <!-- include begin --> <xs:complexType name="Includes"> <xs:sequence> <xs:element name="include" type="Include" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Include" mixed="true" > <xs:attribute name="location" type="xs:string" use="required" /> <xs:attribute name="impldecl" type="xs:string" /> </xs:complexType> <!-- include end --> <!-- resource begin --> <xs:complexType name="Resources"> <xs:sequence> <xs:element name="include" type="Resource" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="slots" type="Slots" minOccurs="0" /> <xs:element name="buttongroups" type="ButtonGroups" <xs:element name="connections" type="Connections" <xs:element name="designerdata" type="DesignerData" <xs:element name="resources" type="Resources" <xs:element name="includes" type="Includes" <xs:element name="images" type="Images" <xs:element name="tabstops" type="TabStops" <xs:element name="customwidgets" type="CustomWidgets" <xs:element name="pixmapfunction" type="xs:string" <xs:element name="layoutfunction" type="LayoutFunction" <xs:element name="exportmacro" type="xs:string"

</xs:sequence> <xs:attribute name="name" type="xs:string" /> </xs:complexType> <xs:complexType name="Resource"> <xs:attribute name="location" type="xs:string" use="required" /> </xs:complexType> <!-- resource end --> <!-- actions begin --> <xs:complexType name="ActionGroup"> <xs:sequence maxOccurs="unbounded"> <xs:element name="action" type="Action" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="actiongroup" type="ActionGroup" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="attribute" type="Property" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="Action"> <xs:sequence maxOccurs="unbounded" > <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="attribute" type="Property" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required" /> <xs:attribute name="menu" type="xs:string" /> </xs:complexType> <xs:complexType name="ActionRef"> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> <!-- actions end --> <!-- button groups begin --> <xs:complexType name="ButtonGroup"> <xs:sequence maxOccurs="unbounded"> <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="attribute" type="Property" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="ButtonGroups"> <xs:sequence> <xs:element name="buttongroup" type="ButtonGroup" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType>

<!--

button groups end -->

<!-- images begin --> <xs:complexType name="Images"> <xs:sequence> <xs:element name="image" type="Image" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Image"> <xs:sequence> <xs:element name="data" type="ImageData" /> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="ImageData" mixed="true" > <xs:attribute name="format" type="xs:string" use="required" /> <xs:attribute name="length" type="xs:integer" use="required" /> </xs:complexType> <!-- images end --> <!-- custom widget support begin --> <xs:complexType name="CustomWidgets"> <xs:sequence> <xs:element name="customwidget" type="CustomWidget" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Header" mixed="true" > <xs:attribute name="location" type="xs:string" /> or global --> </xs:complexType> <!-- local

<xs:complexType name="CustomWidget"> <xs:all> <xs:element name="class" type="xs:string" /> <xs:element name="extends" type="xs:string" /> <xs:element name="header" type="Header" /> <xs:element name="sizehint" type="Size" minOccurs="0" /> <xs:element name="addpagemethod" type="xs:string" minOccurs="0" /> <xs:element name="container" type="xs:integer" minOccurs="0" /> <xs:element name="sizepolicy" type="SizePolicyData" minOccurs="0" /> <xs:element name="pixmap" type="xs:string" minOccurs="0" /> <xs:element name="script" type="Script" minOccurs="0" /> <xs:element name="properties" type="Properties" minOccurs="0" /> <xs:element name="slots" type="Slots" minOccurs="0" /> <xs:element name="propertyspecifications" type="PropertySpecifications" minOccurs="0" />

</xs:all> </xs:complexType> <xs:complexType name="Properties"> <xs:sequence> <xs:element name="property" type="PropertyData" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="PropertyData"> <xs:attribute name="type" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="SizePolicyData"> <xs:all> <xs:element name="hordata" type="xs:integer" /> <xs:element name="verdata" type="xs:integer" /> </xs:all> </xs:complexType> <!-- custom widget support end --> <xs:complexType name="LayoutDefault"> <xs:attribute name="spacing" type="xs:integer" use="required" /> <xs:attribute name="margin" type="xs:integer" use="required" /> </xs:complexType> <xs:complexType name="LayoutFunction"> <xs:attribute name="spacing" type="xs:string" use="required" /> <xs:attribute name="margin" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="TabStops"> <xs:sequence> <xs:element name="tabstop" type="xs:string" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Layout"> <xs:sequence maxOccurs="unbounded" > <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="attribute" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="item" type="LayoutItem" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="class" type="xs:string" use="required" /> <xs:attribute name="name" type="xs:string" /> <xs:attribute name="stretch" type="xs:string" /> <xs:attribute name="rowstretch" type="xs:string" /> <xs:attribute name="columnstretch" type="xs:string" /> <xs:attribute name="rowminimumheight" type="xs:string" /> <xs:attribute name="columnminimumwidth" type="xs:string" /> </xs:complexType>

<xs:complexType name="LayoutItem"> <xs:choice> <xs:element name="widget" type="Widget" /> <xs:element name="layout" type="Layout" /> <xs:element name="spacer" type="Spacer" /> </xs:choice> <xs:attribute name="row" type="xs:integer" /> <xs:attribute name="column" type="xs:integer" /> <xs:attribute name="rowspan" type="xs:integer" /> <xs:attribute name="colspan" type="xs:integer" /> </xs:complexType> <!-- item view begin --> <xs:complexType name="Row"> <xs:sequence> <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Column"> <xs:sequence> <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Item"> <xs:sequence maxOccurs="unbounded"> <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="item" type="Item" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="row" type="xs:integer" /> <xs:attribute name="column" type="xs:integer" /> </xs:complexType> <!-- item view end --> <xs:complexType name="Widget"> <!-- Order does not matter (cannot use xs:all here because of unbounded row, column, item --> <xs:sequence> <xs:element name="class" type="xs:string" minOccurs="0" maxOccurs="unbounded" /> <!-- unbounded kept for compatibility reasons --> <xs:element name="property" type="Property" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="script" type="Script" minOccurs="0" maxOccurs="unbounded" /> <!-- unbounded kept for compatibility reasons --> <xs:element name="widgetdata" type="WidgetData" minOccurs="0" maxOccurs="unbounded" /> <!-- unbounded kept for compatibility reasons --> <xs:element name="attribute" type="Property" minOccurs="0" maxOccurs="unbounded" /> <!-- item view begin --> <xs:element name="row" type="Row" minOccurs="0" maxOccurs="unbounded" />

maxOccurs="unbounded" /> maxOccurs="unbounded" /> <!-- item view end --> <xs:element name="layout" type="Layout" minOccurs="0" maxOccurs="unbounded" /> <!-- unbounded kept for compatibility reasons --> <xs:element name="widget" type="Widget" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="action" type="Action" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="actiongroup" type="ActionGroup" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="addaction" type="ActionRef" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="zorder" type="xs:string" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="class" type="xs:string" use="required" /> <xs:attribute name="name" type="xs:string" /> <xs:attribute name="native" type="xs:boolean" /> </xs:complexType> <xs:complexType name="Spacer"> <xs:sequence> <xs:element name="property" type="Property" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="name" type="xs:string" /> </xs:complexType> <xs:complexType name="Color"> <xs:all> <xs:element name="red" type="xs:integer" /> <xs:element name="green" type="xs:integer" /> <xs:element name="blue" type="xs:integer" /> </xs:all> <xs:attribute name="alpha" type="xs:integer" /> </xs:complexType> <xs:complexType name="GradientStop"> <xs:sequence> <xs:element name="color" type="Color" /> </xs:sequence> <xs:attribute name="position" type="xs:double" use="required" /> </xs:complexType> <xs:complexType name="Gradient"> <xs:sequence> <xs:element name="gradientStop" type="GradientStop" maxOccurs="unbounded" /> </xs:sequence> <xs:attribute name="startx" type="xs:double" use="required" /> <xs:attribute name="starty" type="xs:double" use="required" /> <xs:attribute name="endx" type="xs:double" use="required" /> <xs:attribute name="endy" type="xs:double" use="required" /> <xs:attribute name="centralx" type="xs:double" <xs:element name="item" type="Item" minOccurs="0"

<xs:element name="column" type="Column"

minOccurs="0"

use="required" /> use="required" /> <xs:attribute <xs:attribute <xs:attribute <xs:attribute <xs:attribute <xs:attribute <xs:attribute use="required" /> </xs:complexType> <xs:complexType name="Brush"> <xs:choice> <xs:element name="color" type="Color" /> <xs:element name="texture" type="Property" /> <xs:element name="gradient" type="Gradient" /> </xs:choice> <xs:attribute name="brushstyle" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="ColorRole"> <xs:sequence> <xs:element name="brush" type="Brush" /> </xs:sequence> <xs:attribute name="role" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="ColorGroup"> <xs:sequence maxOccurs="unbounded"> <xs:element name="colorrole" type="ColorRole" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="color" type="Color" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Palette"> <xs:all> <xs:element name="active" type="ColorGroup" /> <xs:element name="inactive" type="ColorGroup" /> <xs:element name="disabled" type="ColorGroup" /> </xs:all> </xs:complexType> <xs:complexType name="Font"> <xs:all> <xs:element name="family" type="xs:string" minOccurs="0" /> <xs:element name="pointsize" type="xs:integer" minOccurs="0" /> <xs:element name="weight" type="xs:integer" minOccurs="0" /> <xs:element name="italic" type="xs:boolean" minOccurs="0" /> <xs:element name="bold" type="xs:boolean" minOccurs="0" name="focalx" type="xs:double" use="required" /> name="focaly" type="xs:double" use="required" /> name="radius" type="xs:double" use="required" /> name="angle" type="xs:double" use="required" /> name="type" type="xs:string" use="required" /> name="spread" type="xs:string" use="required" /> name="coordinatemode" type="xs:string" <xs:attribute name="centraly" type="xs:double"

/> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> minOccurs="0" /> </xs:all> </xs:complexType> <xs:complexType name="Point"> <xs:all> <xs:element name="x" type="xs:integer" /> <xs:element name="y" type="xs:integer" /> </xs:all> </xs:complexType> <xs:complexType name="Rect"> <xs:all> <xs:element name="x" type="xs:integer" /> <xs:element name="y" type="xs:integer" /> <xs:element name="width" type="xs:integer" /> <xs:element name="height" type="xs:integer" /> </xs:all> </xs:complexType> <xs:complexType name="Locale"> <xs:attribute name="language" type="xs:string" use="required" /> <xs:attribute name="country" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="SizePolicy"> <xs:all> <xs:element name="hsizetype" type="xs:integer" minOccurs="0" /> <xs:element name="vsizetype" type="xs:integer" minOccurs="0" /> <xs:element name="horstretch" type="xs:integer" /> <xs:element name="verstretch" type="xs:integer" /> </xs:all> <xs:attribute name="hsizetype" type="xs:string" /> <xs:attribute name="vsizetype" type="xs:string" /> </xs:complexType> <xs:complexType name="Size"> <xs:all> <xs:element name="width" type="xs:integer" /> <xs:element name="height" type="xs:integer" /> </xs:all> </xs:complexType> <xs:complexType name="Date"> <xs:all> <xs:element name="kerning" type="xs:boolean" <xs:element name="stylestrategy" type="xs:string" <xs:element name="antialiasing" type="xs:boolean" <xs:element name="strikeout" type="xs:boolean" <xs:element name="underline" type="xs:boolean"

<xs:element name="year" type="xs:integer" /> <xs:element name="month" type="xs:integer" /> <xs:element name="day" type="xs:integer" /> </xs:all> </xs:complexType> <xs:complexType name="Time"> <xs:all> <xs:element name="hour" type="xs:integer" /> <xs:element name="minute" type="xs:integer" /> <xs:element name="second" type="xs:integer" /> </xs:all> </xs:complexType> <xs:complexType name="DateTime"> <xs:all> <xs:element name="hour" type="xs:integer" /> <xs:element name="minute" type="xs:integer" /> <xs:element name="second" type="xs:integer" /> <xs:element name="year" type="xs:integer" /> <xs:element name="month" type="xs:integer" /> <xs:element name="day" type="xs:integer" /> </xs:all> </xs:complexType> <xs:complexType name="StringList"> <xs:sequence> <xs:element name="string" type="xs:string" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="ResourcePixmap" mixed="true"> <xs:attribute name="resource" type="xs:string" /> <xs:attribute name="alias" type="xs:string" /> </xs:complexType> <xs:complexType name="ResourceIcon" mixed="true"> <xs:all> <xs:element name="normaloff" type="ResourcePixmap" minOccurs="0" /> <xs:element name="normalon" type="ResourcePixmap" minOccurs="0" /> <xs:element name="disabledoff" type="ResourcePixmap" minOccurs="0" /> <xs:element name="disabledon" type="ResourcePixmap" minOccurs="0" /> <xs:element name="activeoff" type="ResourcePixmap" minOccurs="0" /> <xs:element name="activeon" type="ResourcePixmap" minOccurs="0" /> <xs:element name="selectedoff" type="ResourcePixmap" minOccurs="0" /> <xs:element name="selectedon" type="ResourcePixmap" minOccurs="0" /> </xs:all> <xs:attribute name="resource" type="xs:string" /> <!-- pre 4.4 legacy support -->

</xs:complexType> <xs:complexType name="String" mixed="true"> <xs:attribute name="notr" type="xs:string" /> <xs:attribute name="comment" type="xs:string" /> <xs:attribute name="extracomment" type="xs:string" /> </xs:complexType> <xs:complexType name="PointF"> <xs:all> <xs:element name="x" type="xs:double" /> <xs:element name="y" type="xs:double" /> </xs:all> </xs:complexType> <xs:complexType name="RectF"> <xs:all> <xs:element name="x" type="xs:double" /> <xs:element name="y" type="xs:double" /> <xs:element name="width" type="xs:double" /> <xs:element name="height" type="xs:double" /> </xs:all> </xs:complexType> <xs:complexType name="SizeF"> <xs:all> <xs:element name="width" type="xs:double" /> <xs:element name="height" type="xs:double" /> </xs:all> </xs:complexType> <xs:complexType name="Char"> <xs:sequence> <xs:element name="unicode" type="xs:integer" /> </xs:sequence> </xs:complexType> <xs:complexType name="Url"> <xs:sequence> <xs:element name="string" type="String" /> </xs:sequence> </xs:complexType> <xs:complexType name="Property"> <xs:choice> <xs:element name="bool" type="xs:string" /> <xs:element name="color" type="Color" /> <xs:element name="cstring" type="xs:string" /> <xs:element name="cursor" type="xs:integer" /> <xs:element name="cursorshape" type="xs:string" /> <xs:element name="enum" type="xs:string" /> <xs:element name="font" type ="Font" /> <xs:element name="iconset" type="ResourceIcon"/> <xs:element name="pixmap" type="ResourcePixmap" /> <xs:element name="palette" type="Palette" /> <xs:element name="point" type="Point" /> <xs:element name="rect" type="Rect" /> <xs:element name="set" type="xs:string" />

<xs:element name="locale" type="Locale" /> <xs:element name="sizepolicy" type="SizePolicy" /> <xs:element name="size" type="Size" /> <xs:element name="string" type="String" /> <xs:element name="stringlist" type="StringList" /> <xs:element name="number" type="xs:integer" /> <xs:element name="float" type="xs:float" /> <xs:element name="double" type="xs:double" /> <xs:element name="date" type="Date" /> <xs:element name="time" type="Time" /> <xs:element name="datetime" type="DateTime" /> <xs:element name="pointf" type="PointF" /> <xs:element name="rectf" type="RectF" /> <xs:element name="sizef" type="SizeF" /> <xs:element name="longlong" type="xs:long" /> <xs:element name="char" type="Char" /> <xs:element name="url" type="Url" /> <xs:element name="uint" type="xs:unsignedInt" /> <xs:element name="ulonglong" type="xs:unsignedLong" /> <xs:element name="brush" type="Brush" /> </xs:choice> <xs:attribute name="name" type="xs:string" use="required" /> <xs:attribute name="stdset" type="xs:integer" /> </xs:complexType> <xs:complexType name="Connections"> <xs:sequence> <xs:element name="connection" type="Connection" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Connection"> <xs:all> <xs:element name="sender" type="xs:string" /> <xs:element name="signal" type="xs:string" /> <xs:element name="receiver" type="xs:string" /> <xs:element name="slot" type="xs:string" /> <xs:element name="hints" type="ConnectionHints" minOccurs="0" /> </xs:all> </xs:complexType> <xs:complexType name="ConnectionHints"> <xs:sequence> <xs:element name="hint" type="ConnectionHint" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="ConnectionHint"> <xs:all> <xs:element name="x" type="xs:integer"/> <xs:element name="y" type="xs:integer"/> </xs:all> <xs:attribute name="type" type="xs:string" use="required" /> </xs:complexType>

<xs:complexType name="Script"> <xs:attribute name="source" type="xs:string" use="required" /> <xs:attribute name="language" type="xs:string" use="required" /> </xs:complexType> <xs:complexType name="WidgetData"> <xs:sequence> <xs:element name="property" type="Property" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="DesignerData"> <xs:sequence> <xs:element name="property" type="Property" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="Slots"> <xs:sequence maxOccurs="unbounded"> <xs:element name="signal" type="xs:string" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="slot" type="xs:string" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="PropertySpecifications"> <xs:sequence maxOccurs="unbounded"> <xs:element name="stringpropertyspecification" type="StringPropertySpecification" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="StringPropertySpecification"> <xs:attribute name="name" type="xs:string" use="required" /> <xs:attribute name="type" type="xs:string" use="required" /> <xs:attribute name="notr" type="xs:string"/> </xs:complexType> </xs:schema>