Re: Questions about quitting Octave and exit confirmation dialog

[John W. Eaton]

On 10/31/19 12:48 AM, Daniel J Sebald wrote:
> On 10/29/19 1:13 AM, Kai Torben Ohlhus wrote:

> > My impression is, that Octave's GUI dialog and options are good and
> > similar to Matlab, thus need no change.  But with your changes you are
> > addressing bigger issues with exiting on macOS (bug #50025) and so on, I
> > think.
>
> Yes, that sounds familiar.  If there have been upgrades to the 
> save-before-exit of the editor, that's good.  Hopefully some changes 
> John has made recently makes the GUI/core exchange a bit easier.

In a few recent changes, I implemented the "cancel" and "force" options 
for the quit function and made the quit function execute the finish.m 
script instead of having that executed by the list of "atexit" functions.

(1) Now the sequence of events for quitting at the command line is 
(after parsing options) is:

If quitting is not forced, check for confirmation by sending a message 
to the GUI using the event_manager object.  The event manager ultimately 
emits a Qt signal that is connected to a slot function that runs in the 
GUI thread.  This signal/slot connection executes across threads but it 
waits for a result.  That slot checks the settings to see whether the 
"confirm exit" option is set.  If so, it displays a dialog.  Either way, 
it returns true if quitting should proceed.  The interpreter thread 
receives this result and if quitting is confirmed, we throw an 
exit_exception from the quit function that will be caught at the 
top-level of the interpreter evaluation loop.  We use an exception so 
that quitting can work from anywhere in the interpreter and still clean 
up the stack on the way back to the top level.

(2) And the sequence of events when quitting with the GUI by way of the 
closeEvent for the main_window object (which is what happens when you 
use the "close" button on the window manager title bar, for example) is:

In the GUI thread (where the closeEvent function is executing) check the 
settings to see whether the "confirm exit" option is set.  If so, 
display a dialog.  If quitting is confirmed, then we send a message to 
the interpreter to execute the quit function, using an extra option that 
tells it to not check for confirmation since we have already done that.

This method is different from the previous setup where we simply sent a 
message to the interpreter to execute the quit function and it went 
through the procedure described in (1) above.  With the new way, the 
confirmation dialog can be displayed immediately, even if the 
interpreter is busy, and only once quitting is confirmed do we send a 
message to the interpreter.  To actually quit, we still have to wait for 
the interpreter to reach a point where it can respond.  Currently, that 
is only when it is waiting for input at the command prompt.  If the 
interpreter is busy, it is usually possible to use Ctrl-C to interrupt 
the it and then the quit action can proceed.  If the interpreter is 
stuck in some compiled function that can't be interrupted, then you have 
to wait, or kill Octave by other means.  It might be nice to fix that, 
but I don't think it is worth a lot of extra effort at this point.  It 
is the same problem you would have at the command line because there is 
no place to execute "quit" until the prompt is available.

In any case, my intent wasn't really to restructure this just for fun, 
but it came up as part of refactoring other parts of the GUI.  My goal 
for all of this refactoring is primarily trying to figure out how to 
create, start, quit, and delete the Octave GUI and interpreter cleanly.

I would like to make it possible to write an application that uses the 
interpreter (or multiple interpreter objects) as needed, and 
create/destroy them without leaks.

It would also be nice if we could start the GUI from the interpreter 
command line and then exit it to return to the command line.

It's not that I need to do either of these things often (or at all) but 
if we can do it, then I think we will be doing a much better job of 
resource management.  Early on, I made many mistakes with global state 
:-( and I'm still trying to fix them.

Already, most of the important things are members of the interpreter 
class (or members of its components) now.  So we are making progress, 
but it is fairly slow.  Managing the order of deletion in the 
interpreter destructor is still not a fully solved problem but I'm 
trying to work on that next.

jwe