I’m overriding on_close_request() in a class derived from Gtk::ApplicationWindow in order to show a warning dialog when the user attempts to close the app without first performing some cleanup.
The dialog is created OK but I can only see it if I return true from on_close_request() to stall the shutdown. Otherwise the app just closes anyway. It’s as if the ‘modal’ property of the dialog is ignored.
I was using the pre-built gtkmm 4.8.0 that installs on Ubuntu 22.10, but have also tried this with 4.9.3, where I can use the new Gtk::AlertDialog, but with the same result.
I’m guessing that I’m trying to interrupt the shutdown too late but can’t find any earlier signal that I can handle. Any help much appreciated.
Hello, yes, you must always return true from that signal when you want to stall the shutdown, it does not know anything about modal dialogs. The reason for this is because the user could click cancel on the alert and then you would want to avoid the window closing. When the alert dialog returns an affirmative response you can then call .destroy() on the parent window to force it to close.
Or if this is a document-based app you can have additional things like a “save and close” button which can do the save asynchronously, trigger a spinner/progressbar while the save is happening, and then finally call .destroy() when it is done. So you can see how it is important to have that flexibility.
Ah! Thank you. I was expecting execution to be diverted to the dialog and dialog.show() not to return until the user clicked ‘OK’ (or whatever). I think this may be a preconception left over from my days on win32. Amazing what trouble preconceptions can be eh?
That is also how it used to work in older versions of gtk too, you could run a nested main loop inside the signal handler. But this was removed in gtk4 because it causes re-entrancy problems, and the rest of the framework(s) around it has mostly shifted to the async style anyway that avoids the re-entrancy problems.