QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?

[JKSH]

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

Is it by design that exiting the application with QApplication::quit() does not trigger closeEvent() of the main window?

I'm not sure. The best way to find out is to ask the Qt engineers at the Interest mailing list (you must subscribe before posting)

I was under the impression that qApp->quit() is the right way to exit the app, and the right slot to connect the "File -> Exit" menu action to.

Agreed.

But it bypasses QMainWindows::closeEvent(), which often triggers, directly or indirectly, some cleanup and finalization. Bypassing it causes bugs in applications.

I think this is a Qt bug, but I want to make sure before I post a bug report.

I consider quitting an app and closing a window as 2 different, independent actions. I don't think it's a bug, since the user did not explicitly close a window.

Shouldn't should cleanup/finalization be triggered from the window class' destructor instead of a close event?

[JonB]

@JKSH said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

Shouldn't should cleanup/finalization be triggered from the window class' destructor instead of a close event?

A common use of QMainWindow::closeEvent() (I think suggested in docs somewhere) is to ask user if certain settings should be saved for next time, etc. I think that should be happening in closeEvent(), while window is still around and things are relatively safe, not in some final, low-level destructor.

[J.Hilk]

ok 2 fixes

connect(exitAction, &QAction::triggered, qApp, &QApplication::closeAllWindows);

or

//main.cpp
QObject::connect(qApp, &QApplication::aboutToQuit, &mw, &MainWindow::close);

[kshegunov]

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

On the other hand, adding unnecessary Q_OBJECT has significant drawbacks in the resulting binary size, memory footprint, compilation time, and, possibly, startup time.

You should put your money where your mouth is.

@JKSH said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

I consider quitting an app and closing a window as 2 different, independent actions. I don't think it's a bug, since the user did not explicitly close a window.

I agree.

@JonB said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

A common use of QMainWindow::closeEvent() (I think suggested in docs somewhere) is to ask user if certain settings should be saved for next time, etc. I think that should be happening in closeEvent(), while window is still around and things are relatively safe, not in some final, low-level destructor.

And if you need a quick exit, then what do you do if you handle things in the close event? Intercept it with an event filter? And if you have 3-4 top level windows that do things in their close events? It kind of gets spaghetti.

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

Is it by design that exiting the application with QApplication::quit() does not trigger closeEvent() of the main window?

I believe so, yes. You either close the window, or you don't, you chose not to. My advice - connect the button to the window's close slot.

[JonB]

@kshegunov said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

And if you need a quick exit, then what do you do if you handle things in the close event? Intercept it with an event filter? And if you have 3-4 top level windows that do things in their close events? It kind of gets spaghetti.

I don't understand. Where do you save things if not in the closeEvent()? Where else do you get to reject a requested close? BTW, the docs proposed pattern example I was thinking of is at http://doc.qt.io/qt-5/qtwidgets-mainwindows-application-example.html#close-event-handler

[kshegunov]

@JonB said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

I don't understand. Where do you save things if not in the closeEvent()?

I didn't say don't save things in closeEvent, I wrote that closing a window and saving its state (or w/e) isn't part of the program exit semantically - you can have 2 or more top level windows, and you can also want to quit quickly without saving whatever it is - just exit. So if you block in closeEvent and Qt pulls the rug under you by calling close on each window before exiting the event loop, how would you exit quickly?

[JonB]

@kshegunov
I'm still not quite with you, and you know I do value your comments!

1. Does that mean you do not agree with/like the example at http://doc.qt.io/qt-5/qtwidgets-mainwindows-application-example.html#close-event-handler

When the user attempts to close the window, we call the private function maybeSave() to give the user the possibility to save pending changes.

?

2. I am unsure whether you are saying closeEvent should not save state/block/allow user to cancel, or whether you are saying QApplication::quit() should not go via/raise that (if it does) so that it can be a fast exit (with which I do not disagree)?

3. If you answer is that closeEvent cannot block etc. because it could prevent fast-quit, how do you propose to deal with user clicking main window X button instead of going File -> Exit ? You can choose what the latter does, but (so far as I know) you cannot help that the former just calls closeEvent.

[kshegunov]

@JonB said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

1. Does that mean you do not agree with/like the example at http://doc.qt.io/qt-5/qtwidgets-mainwindows-application-example.html#close-event-handler

I have no problem with the example, it's fine.

2. I am unsure whether you are saying closeEvent should not save state/block/allow user to cancel, or whether you are saying QApplication::quit() should not go via/raise that (if it does) so that it can be a fast exit (with which I do not disagree)?

The latter. If you want the code path to go trough the close handler, then by all means close the window. The applications is going to quit (by default) whenever all top level windows have closed.

3. If you answer is that closeEvent cannot block etc. because it could prevent fast-quit, how do you propose to deal with user clicking main window X button instead of going File -> Exit ? You can choose what the latter does, but (so far as I know) you cannot help that the former just calls closeEvent.

Moot due to 2.
What I was saying is that if Qt automatically were to call closeEvent for you when the application quits and you have a blocking closeEvent, then it would be quite impossible to quit quickly (or at least it'd require for you to get upside down to do it).

[Violet Giraffe]

@kshegunov said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

What I was saying is that if Qt automatically were to call closeEvent for you when the application quits and you have a blocking closeEvent, then it would be quite impossible to quit quickly (or at least it'd require for you to get upside down to do it).

What is the importance of quitting quickly (or having the facility to do so) even if the specific Qt client code (main window) may not want to do so?

[Violet Giraffe]

@kshegunov said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

On the other hand, adding unnecessary Q_OBJECT has significant drawbacks in the resulting binary size, memory footprint, compilation time, and, possibly, startup time.

You should put your money where your mouth is.

It absolutely is on compilation time, binary size and memory footprint. Startup time is my speculation. I'm sure there would be a measurable difference, but one would be hard-pressed to create a meaningful example where the impact is pronounced. As for the rest, it's up to you to agree or disagree based on what you find significant or insignificant. I have my own measurements and experience.

[Violet Giraffe]

@J.Hilk said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

ok 2 fixes

connect(exitAction, &QAction::triggered, qApp, &QApplication::closeAllWindows);

or

//main.cpp
QObject::connect(qApp, &QApplication::aboutToQuit, &mw, &MainWindow::close);

Thanks a lot, I did not know about either of these two options.

[JonB]

@kshegunov said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

What I was saying is that if Qt automatically were to call closeEvent for you when the application quits and you have a blocking closeEvent, then it would be quite impossible to quit quickly (or at least it'd require for you to get upside down to do it).

I quite agree with this sentiment. But it was others who were saying (I thought) that QApplication::quit() does invoke closeEvent. Let's hope it does not!

[kshegunov]

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

What is the importance of quitting quickly (or having the facility to do so) even if the specific Qt client code (main window) may not want to do so?

Your client code may not want to do so! Not all applications quit when the last window is closed.

It absolutely is on compilation time, binary size and memory footprint. Startup time is my speculation. I'm sure there would be a measurable difference, but one would be hard-pressed to create a meaningful example where the impact is pronounced. As for the rest, it's up to you to agree or disagree based on what you find significant or insignificant.

Few bytes per class do not constitute significance neither in binary size, nor in startup time. Not to mention memory footprint which is completely unrelated. As for compile time, you may want to test how much the 10-15 template instantiations that are done for each connect translate to the moc-ing of a class.

I have my own measurements and experience.

Maybe.

@JonB said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

Let's hope it does not!

It does not. Never has as far as I know.

[JonB]

@kshegunov said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

It does not. Never has as far as I know.

Ah, OK, I thought people were saying it did.

Now I understand from https://forum.qt.io/topic/9917/order-of-signals-on-application-quitting/2 why the guy is proposing:

connect( actionQuit,
SIGNAL(triggered()),
this,
SLOT(close()) );
connect( actionQuit,
SIGNAL(triggered()),
qApp,
SLOT(quit()) );

He's doing two slots, to do close() followed by quit(). And then there is the discussion about whether the quit flushes the event loop or something.

And so the answer to the OP is that QApplication::quit() was never intended to trigger closeEvent(). And so you would not want just QApplication::quit() to be attached to "File -> Exit" menu action ....

[J.Hilk]

Thats probably my bad, I originally thought, the op expected the class destructor to be called upon QApplication::quit() -Which it should - and not the close event.

[Violet Giraffe]

@kshegunov said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

Your client code may not want to do so! Not all applications quit when the last window is closed.

I'm not saying quit() should be equivalent to closeAllWindows(), quite on contrary. It should, however, quit the application properly, not just call exit(0). I can always do that myself, you know.

Few bytes per class do not constitute significance neither in binary size, nor in startup time.

My small .exe programs and .dll plugins got 20% smaller after I got rid of unnecessary Q_OBJECTs.

Not to mention memory footprint which is completely unrelated.

Uhm.. no, it's not unrelated. Even static data has to be loaded in memory. A marginal cost, I agree, but not zero.

As for compile time, you may want to test how much the 10-15 template instantiations that are done for each connect translate to the moc-ing of a class.

It compares very favorably. Compared to adding extra template connect code to an existing .cpp, calling MOC is a huge overhead in compilation time. A whole extra moc_*.cpp is another huge hit. And MOC calls aren't even invoked in parallel, unlike C++ compilation.

[JonB]

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

I'm not saying quit() should be equivalent to closeAllWindows(), quite on contrary. It should, however, quit the application properly, not just call exit(0). I can always do that myself, you know.

In that case, can we go back to your very original question:

I was under the impression that qApp->quit() is the right way to exit the app, and the right slot to connect the "File -> Exit" menu action to.

Can you supply references for this, especially that it's what File->Exit should do? I'm not trying to dispute here, I'm genuinely interested in this issue.

[JKSH]

@Violet-Giraffe said in QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?:

I'm not saying quit() should be equivalent to closeAllWindows(), quite on contrary. It should, however, quit the application properly, not just call exit(0). I can always do that myself, you know.

Not to worry, it's QCoreApplication::exit(), not the standalone exit() from <cstdlib>.

QCoreApplication::exit() causes QCoreApplication::exec() to return, so control goes back to main().

My small .exe programs and .dll plugins got 20% smaller after I got rid of unnecessary Q_OBJECTs.

You can optimize your program this way if you want. Just be aware that omitting Q_OBJECT makes your QObjects less consistent/correct (for example, myObj->metaObject()->className() will return the wrong name).

[Convaallaria]

This post is deleted!

[LiaoXuewei]

Is this question had been solved? I have the same quetion, but i cann't see the solution.