QStatusBar wrong adjustSize()? When is it calculated?

Edit: forgot to add - I am using Qt 5.15 under Windows 10 MSYS2 MinGW

I am trying to toggle a QStatusBar in my QMainWindow and resize the main window content accordingly. The content has a QLabel with a QPixmap inside a QScrollArea that may or may not be larger than the window, so I calculate the window size manually after each change to the pixmap. In order for the status bar to not overlap the pixmap when it should not be larger than the window, I need to get the status bar size on it's creation so that my resize function can access it. However I cannot figure out how to get the correct size. My status bar toggle looks like this

Code:

---

void toggle_status_bar() { // member of QMainWindow subclass
	if (m_status_bar)
		m_status_bar = nullptr;
	else {
		m_status_bar = new QStatusBar { this };
		m_status_bar->showMessage("some status message");
		m_status_bar->adjustSize(); // * this gives the wrong size ...
	}
	setStatusBar(m_status_bar);
}

---

But here the marked line (// *) calculates the wrong size: it resizes the status bar to height 18. Then my resize function, which is essentially

Code:

---

void resize_content() { // member of QMainWindow subclass
	// calculate new_size ...
	resize(new_size);
}

---

, makes scrollbars appear for the pixmap. If I now request another resize while the program is running, i.e. calling resize_content again, the status bar is resized to height 20 and the scrollbar disappears like it should.
I tried different things at the end of toggle_status_bar(), all of which calculate the wrong height 18:

• Call resize_content()
• Call resize_content() multiple times
• Call update()
• Call m_status_bar->update()
• All of the above
• All of the above, multiple times

The only thing that produces the corrent result is calling

Code:

---

m_status_bar->resize(m_status_bar->width(), 20);

---

after creating the status bar, but this is obviously bad ..

Otherwise, the correct height 20 is only calculated when I request a resize as user during runtime, which I do like this:

Code:

---

void keyPressEvent(QKeyEvent* e) { // member of QLabel subclass that contains the pixmap
	switch(e-key()) {
	//cases ..
		resize_pixmap();
	}
}
void resize_pixmap() { // member of QLabel subclass that contains the pixmap
	// calculate new_size / resize pixmap ...
	emit pixmap_resized(new_size); // this signal is connected to a slot in the QMainWindow sublass that calls resize_content
}

---

I don't know what is the difference between requesting the resize during runtime as opposed to calling resize_content in toggle_status_bar programatically, but I assume there is some interal Qt slot called after resize? Which one, and how to do it programatically? Also I am confused why adjustSize() calculates the wrong status bar size in the first place .. can anyone help?

Quote:

---

Otherwise, the correct height 20 is only calculated when I request a resize as user during runtime

---

Widget geometry cannot be guaranteed to be correct until the parent widget's showEvent() is first called. Until the widget is actually visible on screen, everything could either be wrong or some intermediate value calculated while the layout manager is doing its work. So you cannot get accurate sizes in your widget's constructor or in the resizeEvent() (before isVisible() returns true). You can get accurate geometry in the showEvent() -if- the child widget is visible (which means your status bar must be visible when the widget is first shown) or in the resizeEvent() (if isVisible() for the entire widget returns true).

If your status bar is not initially visible, then trying to retrieve its size might not work because the layout manager hasn't needed to do anything with it. Calling show() on the statusBar() will also not result in an immediately correct result until the event loop has had a chance to run and the layout manager has been able to do its work.

If you want your app to start with the status bar hidden, then there is a trick you can do to get the correct size (in the showEvent()) and then immediately hide it. There might be a blink because the main window will first show with the status bar visible and then immediately redraw with it hidden, but it will probably not be noticeable.

Code:

---

void MainWindow::showEvent( QShowEvent * pEvent )
{
    QStatusBar * pBar = statusBar();
    QRect statusRect = pBar->rect();
 
    // Cause the statusbar to hide immediately after this event
    QTimer::singleShot( 0, pBar, &QWidget::hide );
}

---

Code:

---

void toggle_status_bar() { // member of QMainWindow subclass
	if (m_status_bar)
		m_status_bar = nullptr;
	else {
		m_status_bar = new QStatusBar { this };
		m_status_bar->showMessage("some status message");
		m_status_bar->adjustSize(); // * this gives the wrong size ...
	}
	setStatusBar(m_status_bar);
}

---

Why are you creating a new status bar every time you want to show a new status message? Just access the QMainWindow's built-in status bar (QMainWindow::statusBar()) and hide or show it (with a new message) when you need to.

Code:

---

void toggle_status_bar() { // member of QMainWindow subclass
	if ( statusBar()->isVisible() )
     		statusBar()->hide();
	else {
                statusBar()->showMessage( "some status message" );
                statusBar()->show();
        }
}

---

The only time you want to use QMainWindow::setStatusBar() is when you have derived a custom widget from QStatusBar and want the main window to use your custom widget instead of the built-in one. And even then, you create it once, install it, and then reuse the same one for each new message.

Thanks I think that will help. Somehow I did not think to look for isVisible(), so I created a new one to be able to check for null. But your way makes more sense. I currently redesigned to overlay the status message on top of the label instead, so I don't have to handle additional label resizes ..
Not sure which version I like better, so I may go back and try status bar again with your answer after the commit. Anyway it will help me in the future, thanks for the answer!

Is there some reason why the status bar must be hidden if it isn't showing a message? After all, it takes up very little space and saves you a whole lot of otherwise unnecessary repaints of your main window every time it is shown and hidden.

I really dislike UI that I almost never need take up extra space for no reason in almost every application. One main point of my app is to have absolute minimal UI. Most of the time, there is no UI at all, only the exact content I want to see, nothing else.
I know a program that provides similar functionality (though it still always has a window border, which I find unnecessary as well ..), but I need some other tools that it doesn't provide, so I started writing this. The status (bar) should only be shown when the user (probably myself) explicitly requests some extra information, which most of the time I don't need so it would just be in the way most of the time. So special needs I guess :)

Hmm, I tried the suggestion now and it also does not work.
I removed all new/delete and hide() on the status bar for testing, but it still calculates the wrong size after the first construction of the widgets.

In the constructor of my main window, I only set up the layout and central widget, but not the widgets inside the central widget, because they depend on user choice (only one option is ever called per main window). I have something like

Code:

---

MainWindow::MainWindow() :
		QMainWindow { }, // .. init central widget & layout
	{
	// connect slots / configure layout ..
	// there is no show() here
}
 
MainWindow::open(bool use_scroll) { // this is called from outside MainWindow
	// ..
	if(!m_initialized) use_scroll ? init_with_scroll() : init_without_scroll();
	// line A
	load_content(); // this loads e.g. the pixmap in the label in the with_scroll case
	// line B
}
 
MainWindow::init_with_scroll() {
	// init widgets / add to layouts / connect slots
	// line C
	show();
	// line D
}
 
MainWindow::showEvent(QShowEvent*) {
	std::cout << "height " << statusBar()->height() << std::endl;
}
 
// same procedure for init_without_scroll() ...

---

I tried moving statusBar() between the lines A-D, but first thing I noticed is that in the init_without_scroll() case, the status bar size is always calculated correctly (nvm the grey text, I had a different output in the resize function - the output in showEvent does not differ in the two cases. Though somehow I get the correct value in my resize function in this case, not sure why ..). On the other hand, in the init_with_scroll() case, the status bar height gives different, but always wrong results:

• above code unchanged (first statusBar() inside showEvent): "height 30"
• statusBar() or statusBar()->show() on line C: "height 18"
• statusBar() or statusBar()->show() on line A, B, D: "height 30"

Getting different sizes before and after show() makes sense, but why is it always wrong? I tried to reduce the code to everything I think is relevant, but I guess it looks like there might be an issue somewhere else and I should try to compile a MWE. But for now I guess I will just set the size manually and hope it doesn't change ..

Your code in init_with_scroll() will not provide the correct size no matter where you ask for it, because as I said in my previous post, you have to let the event loop run so that the layout manager can calculate the final geometry of the widget and its layout before it is made visible. This will not happen until after your init function exits and control returns to Qt and the event loop.

So, to reiterate:

- until your widget receives the first showEvent(), no geometry can be guaranteed to be correct.
- geometry will not be correct in the widget constructor
- geometry will not be correct in a resizeEvent() that occurs before the first showEvent()
- any child widgets which are hidden (i.e. isVisible() returns false for them) will probably not have a correct size in the showEvent() either, because the layout manager can ignore them.

If you want to be able to resize your main window to accommodate showing and hiding the status bar, the only time you can get reliable geometry for the status bar is when it and the rest of the widgets are visible. If the status bar is initially hidden, then you cannot get reliable geometry until after you show() it and wait for the event loop to process that so the layout manager can recalculate the whole layout.

I thought the showEvent provided the way to ensure that the event has been processed, say if I call "QMainWindow::showEvent(e);" first. So even then I have to

Quote:

---

... wait for the event loop to process that ...

---

But how can I do that programatically?

* From your first reply

Code:

---

void MainWindow::showEvent( QShowEvent * pEvent )
    {
        QStatusBar * pBar = statusBar();
        QRect statusRect = pBar->rect();
 
        // Cause the statusbar to hide immediately after this event
        QTimer::singleShot( 0, pBar, &QWidget::hide );
}

---

I don't understand what the difference here is to my showEvent(), when I do not hide the statusBar anywhere in my test-code. This constructs the statusBar and then gets its size .. but that is exactly what my print-message outputs?

Quote:

---

say if I call "QMainWindow::showEvent(e);" first.

---

You don't call this. In your main() function in main.cpp, if you declare a MainWindow instance "mw", then the next line "mw.show()" sets up the chain of calls internal to Qt that eventually result in a QShowEvent being placed in the event loop and your MainWindow::showEvent() method being called from within the Qt event loop handler.

You can't force this to happen. There is a reason why all of the Qt events are protected members of QObject or QWidget. Your application code is not supposed to call them. If you want to cause an event to happen there are sendEvent() and p[ostEvent() methods in QApplication to do that. But in general, you don't want to do that, because sometimes even simple method calls can lead to an entire cascade of Qt events

If you want to make a widget visible on screen, you simply call its show() method and let Qt figure out all the steps needed to do that.

The call to QWindow::statusBar() returns the pointer to the QMainWindow status bar. As a side effect, if the status bar instance does not already exist, it creates a standard QStausBar instance and returns it. If you have a MainWindow.ui file that is compiled by UIC and your MainWindow class contains a pointer to the class created by UIC, then calling ui->setupUi( this ) in your MainWindow constructor will create a status bar, since this is included by default in the boilerplate code that creates the ui file. So in fact, the code I put into showEvent() simply gets the pointer that already exists.

The QTimer line is there so that you can create the MainWindow with a status bar already instantiated (and set to be visible), have the window shown so the status bar will have a proper size, and then immediately hide the status bar. That's what the single shot QTimer will do - because it has a zero timeout period, the slot connected to the timeout signal (hide()) will be called immediately, as soon as the showEvent exits and control returns to the event loop.

I see, I am not using ui files for this right now as there is nothing to really "lay out" in my current design.

But still, in this showEvent(), there is no guarantee that the whole window (including status bar) has actually been drawn completely when I call statusBar()->rect(); - or what am I missing? Once the main windows show() is called after construction, all I know is there is some ShowEvent queued that will draw the window and its children at some point in the future ..

Maybe I do not understand the reason for the timer:
First, it is called after pBar->rect();, so it does not help anything with making sure that the statusBar was actually drawn by then.
Second, even if it is called immediately with the timer, does this not just dispatch some sort of internal hide event, that again gets completed whenever Qt has the time for it? What is the difference to just calling hide() directly? And what does it have to do with getting the correct statusBar size?

As far as I understood, the hide was simply to fulfill my need to still have a hidden statusBar by default, even if it needs to be drawn first. But it helps nothing with making sure that it is drawn before I get the size.

If there is no (preferred) way to explicitly wait for an event to finish, is there some signal that Qt emits to notify me when the main window and its children have finished drawing? Then I could connect to this and simply get the size & hide the status bar as soon as I receive this "finished drawing" signal .. ?

Quote:

---

But still, in this showEvent(), there is no guarantee that the whole window (including status bar) has actually been drawn completely when I call statusBar()->rect(); - or what am I missing? Once the main windows show() is called after construction, all I know is there is some ShowEvent queued that will draw the window and its children at some point in the future ..

---

First, you are confusing the showEvent() and the paintEvent(). The showEvent() is called just before the widget is made visible (i.e. painted) on screen. The showEvent() does not draw anything. All geometry calculations and layout are done, nothing is left except to paint it. Painting uses the geometry calculated by the layout system, it does not calculate it on the fly while painting. So you don't "wait for painting to be finished" before getting geometry. It is already there in the showEvent() and resizeEvent() methods, assuming that the things you want geometry for have "true" for their isVisible() status at the time you ask for the geometry. These events are called after the widget geometry has been calculated / recalculated and just before the widget is physically drawn onscreen by the paintEvent().

isVisible() for a child widget simply means that when the widget and its children are drawn onscreen during a paint event, it will be drawn also. It also means that when the layout system is calculating the sizes and positions of everything inside your widget, that child will be included in the calculations. It does not mean it is currently, physically visible on screen.

At the time Qt has put a QShowEvent on the event loop and control reaches your MainWindow's showEvent() method, you can be certain that your widget and every visible child widget will have correct geometry that can be queried.

So the code I wrote with the QTimer is meant to ensure that if the status bar was created earlier (in the MainWindow constructor, either manually or as part of setupUi()) and was set to be visible, then you could retrieve the correct geometry for it (and presumably save it somewhere in your main window class so you could use it when resizing your window to account for the status bar). The QTimer part is there simply to then turn off the status bar immediately so that you app would appear to start up with the status bar hidden.

If there is a child widget which is not instantiated or not visible during the first showEvent() then it won't have valid geometry because the layout system will likely ignore it.

I am not sure what the sequence of Qt events is if you add a new widget or make a hidden widget visible after the first showEvent(). Almost certainly there will be one or more resizeEvent() and paintEvent() calls, as the layout system calculates the new geometry. I doubt that there will be a second showEvent() because the MainWindow is already visible.

Quote:

---

If there is no (preferred) way to explicitly wait for an event to finish,

---

I think you are asking this because of your confusion about what happens at what point in going from a logical description of a widget and its children (widgets, layouts, widget-relative coordinates) to a set of colored pixels in an absolute position on screen.

To beat the dead horse once more, you do not need to wait for "painting" to get the geometry of your widget and its (visible) children. The showEvent() and resizeEvent() are what you wait for, and in those events if the widget you want geometry for returns "true" when asked isVisible(), then the geometry you get will be correct.

If for some reason you need to "wait" for an event to finish, there is really only one practical way, and that is to use the QTimer trick with your own slot. Invoking the QTimer::singleShot() method with a zero timeout period puts the event on the loop and it will be called as soon as possible after the event that is currently being processed exits.

Note that this is not the same as calling your function directly from within the event handler. Your event handler might be only one step in a chain of function calls made to process the event. Some of these might occur before your event handler is invoked, some might be called after it. If you make a direct function call in your event handler, then you are interrupting the normal handling process. If you instead schedule a QTimer event, it guarantees that the timeout slot will not be called until all processing of the current event has been completed (along with any possibly higher priority events in the queue), and then your slot will be invoked.

Sorry if I am making you repeat things. I think I understand the general flow of Qt, but the details are hard to understand with the documentation alone to me, I wish there was more information on many functions. Some events, like key...Event, say you should call the parent class event, other events have no mention of whether I should or should not.

I did not know the exact work show and paint events do when they are called, so this makes it clearer. But there are still details I'm not sure of.
Is it something like

Call constructor of my QMainWindow subclass "MainWindow" > QMainWindow gets constructed > MainWindow gets constructed >
call MainWindow::show() -> Layout system "showEvent" (?) is queued to calculate geometries > some time later: geometries are done calculating, MainWindow showEvent is called > I should get the calculated size here >.. something? queues paintEvent > ...


If this is how it works then I guess there must be something else wrong in my code, since even if I use your showEvent, I get a too-large height of 30. How do I know it is too large? Manually refreshing by hitting a button that calls my resize_content function, which recalculates only the full top-level window size (may or may not be different, same behavior in both cases) and ends in "resize(..." changes the height of status bar to 20.

But I'm repeating my earlier posts now. My resize_content function does need a refactor so maybe it is something in there .. though the only Qt functions I touch in here are statusBar()->isVisible() to determine whether my top level window needs to account for status bar size, and resize(.. at the end. Or it is some entirely different bug. Will have to go back when I decide the priority is high enough to remove this magic number 20 for the status bar from my code.

Quote:

---

Some events, like key...Event, say you should call the parent class event, other events have no mention of whether I should or should not.

---

I agree. Even after 12 years of working with Qt, I still do not know the answers to questions like these.

Quote:

---

Call constructor of my QMainWindow subclass "MainWindow" > QMainWindow gets constructed > MainWindow gets constructed >
call MainWindow::show() -> Layout system "showEvent" (?) is queued to calculate geometries > some time later: geometries are done calculating, MainWindow showEvent is called > I should get the calculated size here >.. something? queues paintEvent > ...

---

It is probably more like:

- Call QMainWindow constructor to get the parent-child pointers set up and do whatever construction QMainWindow (and its base classes) requires
- call setupUi() if you are using a UI file. This constructs the C++ child widgets / layouts / actions / etc. and initializes their parent-child relationships and properties
- or call QWidget constructors directly (via new()) to create child widgets and layouts and set their properties.

- at the end of the MainWindow constructor, there is a logical description of the UI in the form of QWidgets, layouts, and other components. Nothing else happens yet.

- then somewhere, MainWindow:: show() is called (usually in main()). At this point, the Qt layout machinery takes over:

- MainWindow:: resizeEvent() (and possibly other events) are called, sometimes multiple times as the layout system puts the parts of the QWidget / layout hierarchy into place and adjusts their positions and sizes
- MainWindow:: showEvent() is called when all layout is done and the final geometry is set
- MainWindow:: paintEvent() is called to finally render the widget to the screen

When you manually resize the widget, either using the mouse or a call to resize(), then this layout procedure takes place again (minus the final showEvent(), since the widget is already visible), If you show or hide child widgets, the same thing happens. It can be expensive if you have a complex layout or if repainting the content of the centralWidget is expensive. This is one reason why repeatedly toggling the visibility of the status bar might be a false optimization - the layout (and possibly repainting) might actually happen twice - once when you show or hide the status bar, then again when you resize the centralWidget to take account of its presence or absence.

The status bar does not live in isolation. It is probably contained within a QFrame within the MainWindow, which itself has dimensions. The frame could have a margin around its content, the main window's layout could have a margin around the frame, and so forth. So showing or hiding the status bar also must show or hide its container, and that geometry must be taken into account by the re-layout code. So the delta between the size you retrieve for the status bar itself and what you retrieve for the entire main window probably accounts for this extra decoration placed around the status bar.

And remember that resizeEvent() might happen more than once during the layout before the final geometry is established. This will be especially true if you change the visibility of something in the layout - not only does the layout manager have to scale the contents of the widget to their new sizes, if you add or remove something, then it might have to layout the entire thing from scratch.