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

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

[JKSH]

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

Is this question had been solved? I have the same quetion

Answers below:

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

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.

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)

[LiaoXuewei]

@JKSH
Thks for replay!
But, for example, user close qt app by taskbar, but app cann't detect. Do you think it's normal?

[LiaoXuewei]

Hi, all:
I am sorry, i had made a mistake.
I had test QApplication::quit() will trigger closeEvent() of the main window!
I had wrote closeEvent in sub window before, so did not trigger!

[JKSH]

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

I had test QApplication::quit() will trigger closeEvent() of the main window!
I had wrote closeEvent in sub window before, so did not trigger!

Ah, thank you for sharing your findings!

So quit() triggers the closeEvent() on a top-level window but not a subwindow.

[PatriciaDowning]

This post is deleted!