Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QApplication::quit() does not trigger closeEvent() of the main window: by design or bug?
Forum Updated to NodeBB v4.3 + New Features

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

Scheduled Pinned Locked Moved Unsolved General and Desktop
38 Posts 8 Posters 21.8k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • J.HilkJ J.Hilk

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

    but with the new C++11 connection syntax it's no longer required for the connection target to have Q_OBJECT.

    It's sadly a bit more complicated than that.

    You don't need to to specify slots any longer, true, but the target class/object needs Qobjects somewhere as its base class, or it won't work.

    You can trick the system somewhat, by using a Lambda, but that falls also flat if you to to do the connect via the static call of Qobject::connect, inside the class that is not based on QObject.

    V Offline
    V Offline
    Violet Giraffe
    wrote on last edited by
    #13

    @J.Hilk, you're right, the connection target also has to be a QObject, but it does not need to have the Q_OBJECT macro. In practice, this means most classes don't need the macro, especially if you take a little effort to avoid needing it. The compilation speedup from omitting the macro is not insignificant.

    Now, back to the issue at hand: I've added Q_OBJECT to my main window subclass, I set a.setQuitOnLastWindowClosed(true);, and I use Qt::QueuedConnection on the qApp->quit() slot. Guess what? Still no close event.

    1 Reply Last reply
    0
    • V Violet Giraffe

      Is it by design that exiting the application with QApplication::quit() does not trigger closeEvent() of the main window? 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. 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.

      JKSHJ Offline
      JKSHJ Offline
      JKSH
      Moderators
      wrote on last edited by
      #14

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

      Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

      JonBJ 1 Reply Last reply
      2
      • JKSHJ 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?

        JonBJ Offline
        JonBJ Offline
        JonB
        wrote on last edited by
        #15

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

        1 Reply Last reply
        2
        • J.HilkJ Offline
          J.HilkJ Offline
          J.Hilk
          Moderators
          wrote on last edited by
          #16

          ok 2 fixes

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

          or

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

          Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


          Q: What's that?
          A: It's blue light.
          Q: What does it do?
          A: It turns blue.

          V 1 Reply Last reply
          3
          • V Violet Giraffe

            @J-Hilk : I don't believe the Q_OBJECT macro is strictly always required. It's only required when the class needs to use the Qt meta compiler (e. g. to emit a signal), but my class does not need that. On the other hand, adding unnecessary Q_OBJECT has significant drawbacks in the resulting binary size, memory footprint, compilation time, and, possibly, startup time.

            kshegunovK Offline
            kshegunovK Offline
            kshegunov
            Moderators
            wrote on last edited by kshegunov
            #17

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

            Read and abide by the Qt Code of Conduct

            JonBJ V 2 Replies Last reply
            1
            • kshegunovK 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.

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by
              #18

              @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

              kshegunovK 1 Reply Last reply
              0
              • JonBJ 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

                kshegunovK Offline
                kshegunovK Offline
                kshegunov
                Moderators
                wrote on last edited by kshegunov
                #19

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

                Read and abide by the Qt Code of Conduct

                JonBJ 1 Reply Last reply
                0
                • kshegunovK 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?

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by JonB
                  #20

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

                  ?

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

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

                  kshegunovK 1 Reply Last reply
                  0
                  • JonBJ 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.

                    ?

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

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

                    kshegunovK Offline
                    kshegunovK Offline
                    kshegunov
                    Moderators
                    wrote on last edited by kshegunov
                    #21

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

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

                    1. 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).

                    Read and abide by the Qt Code of Conduct

                    V JonBJ 2 Replies Last reply
                    1
                    • kshegunovK 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.

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

                      1. 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).

                      V Offline
                      V Offline
                      Violet Giraffe
                      wrote on last edited by
                      #22

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

                      kshegunovK 1 Reply Last reply
                      0
                      • kshegunovK 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.

                        V Offline
                        V Offline
                        Violet Giraffe
                        wrote on last edited by
                        #23

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

                        1 Reply Last reply
                        0
                        • J.HilkJ J.Hilk

                          ok 2 fixes

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

                          or

                          //main.cpp
                          QObject::connect(qApp, &QApplication::aboutToQuit, &mw, &MainWindow::close);
                          
                          V Offline
                          V Offline
                          Violet Giraffe
                          wrote on last edited by
                          #24

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

                          1 Reply Last reply
                          0
                          • kshegunovK 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.

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

                            1. 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).

                            JonBJ Offline
                            JonBJ Offline
                            JonB
                            wrote on last edited by
                            #25

                            @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!

                            1 Reply Last reply
                            0
                            • V 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?

                              kshegunovK Offline
                              kshegunovK Offline
                              kshegunov
                              Moderators
                              wrote on last edited by kshegunov
                              #26

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

                              Read and abide by the Qt Code of Conduct

                              JonBJ V 2 Replies Last reply
                              0
                              • kshegunovK 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.

                                JonBJ Offline
                                JonBJ Offline
                                JonB
                                wrote on last edited by JonB
                                #27

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

                                1 Reply Last reply
                                0
                                • J.HilkJ Offline
                                  J.HilkJ Offline
                                  J.Hilk
                                  Moderators
                                  wrote on last edited by
                                  #28

                                  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.


                                  Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


                                  Q: What's that?
                                  A: It's blue light.
                                  Q: What does it do?
                                  A: It turns blue.

                                  1 Reply Last reply
                                  0
                                  • kshegunovK 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.

                                    V Offline
                                    V Offline
                                    Violet Giraffe
                                    wrote on last edited by JKSH
                                    #29

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

                                    JonBJ JKSHJ 2 Replies Last reply
                                    0
                                    • V 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.

                                      JonBJ Offline
                                      JonBJ Offline
                                      JonB
                                      wrote on last edited by JonB
                                      #30

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

                                      1 Reply Last reply
                                      0
                                      • V 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.

                                        JKSHJ Offline
                                        JKSHJ Offline
                                        JKSH
                                        Moderators
                                        wrote on last edited by
                                        #31

                                        @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).

                                        Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches

                                        1 Reply Last reply
                                        4
                                        • C Offline
                                          C Offline
                                          Convaallaria
                                          Banned
                                          wrote on last edited by Convaallaria
                                          #32
                                          This post is deleted!
                                          1 Reply Last reply
                                          0

                                          • Login

                                          • Login or register to search.
                                          • First post
                                            Last post
                                          0
                                          • Categories
                                          • Recent
                                          • Tags
                                          • Popular
                                          • Users
                                          • Groups
                                          • Search
                                          • Get Qt Extensions
                                          • Unsolved