@SGaist Thank you very much. One last questions before closing this thread:

Does using setListWigetItem (QListWidget) make an difference in performance compared to just using the widgets inside a scrollarea or is the overhead the same?

Have a nice day! :)

@Hai-Anh-Luu Welcome to the forum.

Until the widget is displayed its size, and the size of any child widget in a layout, is unknown. In the widget class constructor^^ the widget is not yet shown so you get either the size hint from the widget concerned or some other value.

^^ That is when executing this line window = NewGrid()

One way to see the size that is initially allocated is to do so in a slot connected to a zero-length (or very short) single-shot QTimer. This will fire when the event loop is reached, after the UI is shown. That is when app.exec() is running.

@ChrisW67 Thanks for replying. I was doing as you suggested but still getting the behaviour I specified. Turns out I had a conflicting ui generated header file that had the manually added layout which explains why I was experiencing a NULL layout. Once I deleted the conflicting file everything worked as expected.
Thanks for the extremely easy to follow instructions.

Kevin

Kind of solved. If I set sizeAdjustPolicy to AdjustToContents and sizePolicy to Maximum, the list widget size will adjust to accomodate items plus small margins around them. I'm quite happy with the result, it would be even better if I could make items equally distribute across available space, but even now it looks good enough.

@firen Read "Size Hints and Size Policies" in https://doc.qt.io/qt-5/qwidget.html

@sm4ll-3gg said in How to resize QListView row to index widget size:

what I should read to better understand Model / View / Delegate programming?

Basically everything I know comes from Advanced Qt Prgramming: Creating Great Software with C++ and Qt4

It is normal to set new delegate for each item if I need to show heterogeneous data in list?

No. What I would do is create a QStackedWidget with the possible combinations, use that as base and display the correct page based on the data in the index

Terribly sorry, but it turned out to be my fault all along.

The line responsible was:

textDoc.setDocumentMargin(0);

in the sizeHint() method.

Can you run a little test ?

What do you get if you call qDebug() << yourToolBox->sizeHint(); before and after it's shown ?

The thing is that toolbars don't really display icons. They display widgets (that can have icons). By default when you add an action to a toolbar a QToolButton is created for it, but you are not limited to that and can add any widget e.g. an expanding line edit, combobox or a button with an icon and text. All of these can have different size policies, be expanding or have a custom stylesheet applied.
All of this makes calculating such size not feasible because how would you calculate it if a widget can change its size.

What I'm saying is that yours is a special, very specific case (with just icons), and as such you need to handle it yourself if you want to.

To answer your questions:

It's not one thing that adds the space. There are couple of aspects that can contribute. You can control some(or all?) of them with stylesheets e.g. set padding of the toolbar and toolbuttons to 0 and margins and borders of the toolbuttons. By default all of these depend on a style and will vary across computers. You also need to be careful to consider the size of the toolbar handle (if it's movable) as its size depends on the active style. You also need to consider that if the icon is narrower than the iconSize then there's gonna by space left anyway. nope, AFAIK it can vary from one item of the toolbar to another if you set it this way nope and just out of curiosity - why do you need that? The bar will display an arrow button that will let you see the overflowing items. Also such calculated size would be useless as the window can be resized and thus the toolbar too (unless you're doing some really fancy layout).