OSX - Handling 'Quit' from Dock Icon context menu



  • For some reason, 'Quit' from the application's icon in the OSX dock doesn't seem to signal quit to my QGuiApplication. I can choose quit, and nothing happens.

    For those of you who build for OSX - how do you trap a 'right click, choose Quit, from the application icon in the Dock panel'?

    I've seen two approaches that are supposed to work:

    1. Install an event filter on the application object.

    I have done this, and I catch minimize/restore signals (come in as QExposeEvents) from the dock; however, I do not receive any events when Quit is chosen.

    1. Subclass the QGuiApplication class and override ::notify()

    I have NOT done this yet (I'm about to) - but my understanding was that notify was fed from the event system just like an event filter, except farther down the chain.

    Has anyone personally done this (as opposed to speculation ;) )?

    Thanks!

    Hans

  • Lifetime Qt Champion

    Hi,

    Always worked for me.

    Are you doing any menu setup in your application ?



  • @SGaist I'm not doing anything with menus (this QGuiApplication is creating a Qml Window.)

    When you say "always worked for me" - what do you mean? Option #1 worked for you? #2 worked? Or, you didn't need to do either of those things...?

    Thanks,

    Hans

  • Lifetime Qt Champion

    #3 Nothing special needed.

    Can you provide a minimal compilable example that shows that behaviour on your machine ?

    By the way, which version of Qt, Xcode and macOS are you using ?



  • Dirty code but is run...
    and Dock exit go to prepare_to_close....
    All close if yess button is pressed...
    other way stay open for other staff...

    https://codebeautify.org/cpp-formatter-beautifier

    
    QMainwindow:
    
    void MainWin::closeEvent (QCloseEvent *event) {
        event->ignore();
        emit request_to_close();
    }
    
          fileMenu = menubarre->addMenu(tr("&File"));
          QAction *act_file_open = new QAction(QTR("Open Fake File"), this);
          act_file_open->setShortcut(QKeySequence(QKeySequence::Open));
          connect(act_file_open, SIGNAL(triggered()),this, SLOT(request_open_file()));
          fileMenu->addAction(act_file_open);
    
    
    
    on top subclass QApplication
    
    macdocks->addAction(QTR("&Mac Exit Test"),this, SLOT(prepare_to_close()));
    
    
    connect(win, SIGNAL(request_to_close()),this, SLOT(prepare_to_close()));
    
    
    void RDoc::prepare_to_close() {
        qDebug() << "### prepare_to_close";
        QMessageBox::StandardButton resBtn = QMessageBox::question(win,QTR("Speacker"),
                                                                   QTR("Are you sure to quit?\n"),
                                                                   QMessageBox::Cancel | QMessageBox::No | QMessageBox::Yes,
                                                                   QMessageBox::Yes);
        const int permission = (int)resBtn;
        if ( permission == 16384 ) {
           QApplication::quit();
           return;
        }
        emit eventLog(QTR("Continue to Speack..."));
    }
    


  • @SGaist I found the cause of the problem; however, I'm not sure how to fix/alleviate/work-around it.

    I recently had to add a protocol handler on OSX, and I REALLY wanted to do it in a Qt only (not writing native Apple code) fashion.

    The other requirement that applied is that my application needs to potentially operate as a GUI application or as a headless command line application; ergo, I need to check for a protocol handler event before knowing if my application should use QGuiApplication or QCoreApplication.

    This was possible by, early in the main, creating a temporary QGuiApplication (which hooks into Apple's event notification system whereas QCoreApplication does not) and overriding event notification to catch the protocol handler request. This was done by running the temporary application object for a second and terminating it with a one-shot timer. This is a hack, but the value of keeping the codebase Qt only is deemed greater.

    The temporary QGuiApplication object goes completely out of scope and is torn down after this happens and either a permanent QCoreApplication or permanent QGuiApplication is created and executed (depending upon how the application is started and/or options are passed.)

    This second, permanent, QGuiApplication apparently is not being wired up to the Dock quit which, I presume, was created by the temporary QGuiApplication object...

    Hmmm...


  • Lifetime Qt Champion

    Can you post a minimal sample that shows how you did it and reproduces the behaviour ?



  • @SGaist I'll try to do so as soon as I get a chance (nearing the end of a release right now, so zero time, apologies.)


Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.