OSX - Handling 'Quit' from Dock Icon context menu

VRHans

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:

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.

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

SGaist

Hi,

Always worked for me.

Are you doing any menu setup in your application ?

VRHans

@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

SGaist

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

patrik08

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..."));
}

VRHans

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

SGaist

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

VRHans

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

brktim

One thing to watch out is that if you don't set a menu role, Qt seems to use QAction::TextHeuristicRole as default. Thus, if you happen to have another menu item with the word 'Quit' in its label then Qt might assign that menu item to the quit role. This just happened to me, and once I set QAction::NoRole for all other non-role-specific menu items, everything worked again.