Arrange widgets properly on a layout

[J.Hilk]

@tomy the easiest way to deal with this is to set the stretch factor of the columns either via designer or by code.

stretch factor of 1, 2 will result in 1/3 width of column 1 and 2/3 width of column 2

[tomy]

Thanks all,

The QFormLayout looks nice and applicable, with much less code:

#include "dateofhire.h"

#include <QLineEdit>
#include <QDateEdit>
#include <QPushButton>
#include <QFormLayout>

DateOfHire::DateOfHire(QWidget *parent)
    : QDialog(parent)
{
    nameLineEdit = new QLineEdit;
    titleLineEdit = new QLineEdit;
    hireDateEdit = new QDateEdit;
    ok = new QPushButton(tr("&OK"));

    QFormLayout* form = new QFormLayout;
    form->addRow(tr("Name"), nameLineEdit);
    form->addRow(tr("Title"), titleLineEdit);
    form->addRow(tr("Hire"), hireDateEdit);
    form->addWidget(ok);

    setLayout(form);
}

The result looks:

While I need some Stretch for the button to look:

@J-Hilk: Do you mean to use Q[V/H]BoxLayouts but add stretch for the layouts and the button, please? I only use pure code not designer.

[VRonin]

Just set a QVBoxLayout as the main layout of the widget and add the buttonbox at the bottom. Use QFormLayout only for the form-like part of the widget and another layout for the rest

Side note, dialogs standard buttons should use QDialogButtonBox instead of manual QPushButton to look native on all platforms

DateOfHire::DateOfHire(QWidget *parent)
    : QDialog(parent)
{
    nameLineEdit = new QLineEdit(this);
    titleLineEdit = new QLineEdit(this);
    hireDateEdit = new QDateEdit(this);
    buttonBox = new QDialogButtonBox(QDialogButtonBox::Ok, this);
    connect(buttonBox, &QDialogButtonBox::accepted, this, &QDialog::accept);

    QFormLayout* form = new QFormLayout;
    form->addRow(tr("Name"), nameLineEdit);
    form->addRow(tr("Title"), titleLineEdit);
    form->addRow(tr("Hire"), hireDateEdit);
    auto mainLay = new QVBoxLayout(this);
    mainLay->addlayout(form);
    mainLay->addWidget(buttonBox);
    
}

[tomy]

@VRonin

Thank you. It worked.

dialogs standard buttons should use QDialogButtonBox instead of manual QPushButton to look native on all platforms

It doesn't look differently from a manual button on my Windows machine!

I also used:

mainLayout->addStretch();

But why have you parented all those many widgets? They are all automatically parented by layouts.

DateOfHire::DateOfHire(QWidget *parent)
    : QDialog(parent)
{
    nameLineEdit = new QLineEdit;
    titleLineEdit = new QLineEdit;
    hireDateEdit = new QDateEdit;
    ok = new QDialogButtonBox(QDialogButtonBox::Ok);

    QFormLayout* form = new QFormLayout;
    form->addRow(tr("Name"), nameLineEdit);
    form->addRow(tr("Title"), titleLineEdit);
    form->addRow(tr("Hire"), hireDateEdit);

    auto mainLayout = new QVBoxLayout;
    mainLayout->addLayout(form);
    mainLayout->addStretch();
    mainLayout->addWidget(ok);

    setLayout(mainLayout);
}

[JonB]

@tomy said in Arrange widgets properly on a layout:

It doesn't look differently from a manual button on my Windows machine!

Well it may do elsewhere. And QDialogButtonBox can also be about the layout/positioning of the buttons, not just their look. See the examples at https://doc.qt.io/archives/qt-4.8/qdialogbuttonbox.html#details.

But why have you parented all those many widgets? They are all automatically parented by layouts.

This is a matter of style, and @VRonin chooses to parent all of his explicitly. Nothing wrong with that. I admit I don't if I'm about to put them on something, but then I am obsessive about the least possible amount of typing :) @VRonin's code will, for example, be less likely to leak if for whatever reason you exit the method early, or hide something without adding it to a layout.

[J.Hilk]

@tomy said in Arrange widgets properly on a layout:

@J-Hilk: Do you mean to use Q[V/H]BoxLayouts but add stretch for the layouts and the button, please? I only use pure code not designer.

I meant
https://doc.qt.io/qt-5/qboxlayout.html#setStretch

myLayout->setStretch(0,1);
myLayout->setStretch(1,2);

@JonB It's not entirely style only.

Reparenting will cause a chain of recalculating in the layout and other stuff. It's usually more efficient so create layout items without a parent ;)

[JonB]

@J-Hilk said in Arrange widgets properly on a layout:

@JonB It's not entirely style only.
Reparenting will cause a chain of recalculating in the layout and other stuff. It's usually more efficient so create layout items without a parent ;)

I don't understand. In the code @VRonin pasted, what reparenting will be going on?

nameLineEdit = new QLineEdit(this);
form->addRow(tr("Name"), nameLineEdit);

After the second line, how will the parent be any different from the this he passes as parent in the first line?

[J.Hilk]

@JonB from here
https://doc.qt.io/archives/qt-4.8/layout.html

Tips for Using Layouts

When you use a layout, you do not need to pass a parent when constructing the child widgets. The layout will automatically reparent the widgets (using QWidget::setParent()) so that they are children of the widget on which the layout is installed.

Note: Widgets in a layout are children of the widget on which the layout is installed, not of the layout itself. Widgets can only have other widgets as parent, not layouts.

You can nest layouts using addLayout() on a layout; the inner layout then becomes a child of the layout it is inserted into.

so, you're right in this example, the overall parent will be the widget that was the parent for the lineEdit, but only at the end.

The Layout does not have an owner in the beginning, so I assume(haven't checked) it will reparent to a null ptr and then reparent the the original parent, when it's assigned to a widget

[VRonin]

@J-Hilk said in Arrange widgets properly on a layout:

Reparenting will cause a chain of recalculating in the layout and other stuff. It's usually more efficient so create layout items without a parent ;)

Layouts are QObjects, not QWidgets so they don't own widgets.
The parent of a widget will always be a widget so in my code above there is no reparenting going on at all.
Passing the parent in the constructor is just one of those things that sometimes don't do anything but you never want to forget when it's needed, hence I always parent QObjects on construction when I can.

[JonB]

@J-Hilk said in Arrange widgets properly on a layout:

The Layout does not have an owner in the beginning, so I assume(haven't checked) it will reparent to a null ptr and then reparent the the original parent, when it's assigned to a widget

Hmm. So you're saying when he goes form->addRow(tr("Name"), nameLineEdit); that will unparent the widget, and only later reset it to the original this parent when he later ultimately goes setLayout(mainLayout); causing everything to reparent, is that right?

EDIT I see @VRonin has just come to hos own defence! Saying what I said. Clearly this needs investigation if I really want to know what is going on....

[VRonin]

@JonB said in Arrange widgets properly on a layout:

So you're saying when he goes form->addRow(tr("Name"), nameLineEdit); that will unparent the widget, and only later reset it to the original this parent when he later ultimately goes setLayout(mainLayout); causing everything to reparent, is that right?

Nope. If the layout is not set on a widget it will not change parenting of widgets added to it. Source: https://code.woboq.org/qt5/qtbase/src/widgets/kernel/qlayout.cpp.html#_ZN7QLayout14addChildWidgetEP7QWidget

[JonB]

@VRonin said in Arrange widgets properly on a layout:

Nope. If the layout is not set on a widget it will not change parenting of widgets added to it.

That's what I thought! Now I don't know whom to believe... ;-) I respect both you & @J-Hilk , I'm torn....

[J.Hilk]

I said I assume ;) it reparents to nullptr

so clearly I was wrong 🙈

[tomy]

I tend to use parenting using the layouts and find it better and nicer (less verbose).
But how could "exiting the method early" happen in an example, please?

[VRonin]

I tend to use parenting using the layouts and find it better and nicer (less verbose).

it's just personal preference, both methods are basically equivalent

But how could "exiting the method early" happen in an example, please?

for example if something throws before you set the layout you leak memory. not a problem in this code

[JonB]

@tomy said in Arrange widgets properly on a layout:

But how could "exiting the method early" happen in an example, please?

Apart from throwing, if a developer puts in e.g. a if (...) return statement. Or an if generally, and a widget is left unparented, for whatever reason. You & I might notice, someone else might not :) Just saying.

[tomy]

@JonB

I see these scenarios, yeah, but these may happen much rarely. Normally constructor's code is quite clean, straightforward and without these stuff.