[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about quitting Octave and exit confirmation dialog

From: Daniel J Sebald
Subject: Re: Questions about quitting Octave and exit confirmation dialog
Date: Thu, 31 Oct 2019 02:54:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 10/31/19 1:58 AM, John W. Eaton wrote:
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

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:

Utilizing a closeEvent to take the program down the same path as the framework's close operation is a great idea.

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.

This all sounds like it is in the right direction.

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.

From what you describe you've moved the flow more along the lines of Qt's design such that solutions to some of these other issues should become easily evident. That's the way it usually goes. Get near a good design and it's, "Hey wait, why don't I just to this?"


reply via email to

[Prev in Thread] Current Thread [Next in Thread]