QStatusBar wrong adjustSize()? When is it calculated?

[Maryu]

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 .. ?

[d_stranz]

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.

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.

[Maryu]

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.

[d_stranz]

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.

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.