Horizontal and Vertical Layout

QLayout as an abstract base class only covers the basic functions for layouts. Spe-cific strategies, such as the already familiar horizontal or vertical layout, are looked after by the special Qt clusters shown in Figure 5.2 inheriting from QLayout.

Thus the QVBoxLayout class, used in the example on page 29 and the following pages, arranges widgets among themselves, vertically. Here the order in which the widgets are included in the layout using addWidget() is crucial.

The example from page 142 now appears as follows:

// vertically/window.cpp

#include <QtGui>

#include "window.h"

Window::Window(QWidget *parent) : QWidget(parent) {

resize(640, 480);

QVBoxLayout *lay = new QVBoxLayout(this);

QTextEdit *txt = new QTextEdit(this);

lay->addWidget(txt);

QPushButton *btn = new QPushButton(tr("&Close"), this);

lay->addWidget(btn);

}

The resize() instruction is not absolutely necessary. Without it, Qt adds the mini-mum sizes of the editor window and the button suggested by minimini-mumSizeHint() to thespacinginserted by the layout, that is, the distance between two widgets in a layout. In addition it adds amarginfor the layout and fixes the window size to the total.

Figure 5.3:

The widget with a vertical layout

Figure 5.3 clearly shows the weaknesses of the vertical layout: The button takes over the full width, which is not what we had in mind.

There are two ways of overcoming this problem. In the first case we make use of something we are already familiar with, and take a look at the API documenta-tion of QBoxLayout,³the class from which QVBoxLayout inherits: The addWidget() method actually has two other parameters, stretch and alignment. The latter looks after the horizontal alignment of a widget. It is now possible to arrange the button correctly, thanks to Qt::AlignRight.

To do this, we simply replace the last two lines of code above with the following:

QPushButton *btn = new QPushButton(tr("&Close"), this);

lay->addWidget(btn, 0, Qt::AlignRight);

You should try this method, particularly if you had trouble with the grid layout described in Chapter 5.2.2. Grid layouts remain the better choice, particularly for

3 See http://doc.trolltech.com/4.1/qboxlayout.html.

more complex layouts, in which you can easily lose track of what is lined up where when using box layouts.

Box layouts have an additional property which we have so far ignored, the so-calledstretchfactor. If this does not equal 0, it determines the proportional space occupied by the widget in the overall layout, in the direction of the box layout.

This assumes, of course, that the widget is interested in spreading out in this par-ticular direction. It does not make any sense for a button, for example, to stretch out vertically above the height or below the depth of the text or the icon that it displays.

If this should still be necessary, however, thesize policycan be adjusted using set-SizePolicy(). The method expects two parameters here from the QSizePolicy::Policy enumerator (see Table 5.1), which define the size guidelines for the horizontal and vertical stretches.

Table 5.1:

The EnumeratorPolicy Value Meaning

QSizePolicy::Fixed The widget may never have a size other than sizeHint().

QSizePolicy::Minimum sizeHint() is the smallest acceptable size for the widget, but the widget may be en-larged as much as you want.

QSizePolicy::Maximum sizeHint() is the largest acceptable size for the widget, but the widget may be re-duced in size as much as you want.

QSizePolicy::Preferred sizeHint() is the optimal size, but the widget may be either larger or smaller than this value (default for QWidget).

QSizePolicy::Expanding As Preferred, but the widget demands any available space in the layout.

QSizePolicy::MinimumExpanding As Minimum, but the widget absolutely demands any available space in the lay-out.

QSizePolicy::Ignored Ignore sizeHint()—the widget is given as much space as possible in the layout.

But let’s return to the stretch factor: This is illustrated by the following code ex-ample, which places five stretchable text edits next to each other, but assigns a different stretch to each of them:

// stretchfactors/main.cpp

#include <QtGui>

int main(int argc, char *argv[]) {

QApplication a(argc, argv);

QWidget w;

QHBoxLayout lay(&w);

QTextEdit *txtEdit = 0;

for (int stretch = 1; stretch <= 5; stretch++) { txtEdit = new QTextEdit(&w);

lay.addWidget(txtEdit, stretch);

}

w.show();

return a.exec();

}

We choose a horizontal layout in this example and insert dynamically generated text fields into it. These contain a stretch factor of 1 to 5, according to the status of the loop counter. As can be seen in Figure 5.4, the widgets now take up more space, increasing from left to right according to their factor. Thus the second text field has twice as much space as the first one, the third, three times as much, and so on.

The text edit behaves strangely as soon as the horizontal window size is reduced:

Although all widgets become proportionately smaller, they always try to attain their smallest possible size (minimumSize()), which is always the same despite the stretch factor. Therefore, all the text fields in our example are the same size as soon as the window has reached its minimum size.

Figure 5.4:

Stretch factors provide individual widgets with more space.

While horizontal stretches seldom cause problems, hardly any widget wants to be stretched vertically. However, if the user expands a dialog lengthways, the layouts insert ugly spaces between all the GUI elements contained in the dialog window.

This can also be avoided using manually defined spaces. One approach is to define a stretch factor in one of the addWiget() calls for a single position, to define a

pretetermined breaking point, so to speak. An alternative is to use addStretch() to add a stretch of any size to the end of the layout (that is, at the lower or right edge, depending on the layout type).