Questions about quitting Octave and exit confirmation dialog

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Questions about quitting Octave and exit confirmation dialog

John W. Eaton
Administrator
I'm trying to improve the way Octave behaves when exiting and would like
to understand what Matlab users might expect.

Does Matlab offer a "confirm before quitting" option for its GUI?

Does that action work when quit is called from a function, or only when
it is executed at the command line or when Matlab is closed using some
"exit applcation" button in the GUI?

If confirmation is requested when the quit function is called from a
function, what does the quit function do?  Here is an example:

   function myquit ()
      quit;
      disp ('foo-i-hithere');
   end

If you call this function and a quit confirmation dialog is shown and
quitting is NOT confirmed, does execution continue immediately after the
call to "quit" so that the message displayed?  Or does execution resume
at the top-level command prompt with no message displayed?  I'm trying
to determine whether the quit function interrupts the execution of a
program (similar to Control-C) even if the quit action is not confirmed.

Thanks,

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Questions about quitting Octave and exit confirmation dialog

Daniel Sebald
On 10/28/19 3:38 PM, John W. Eaton wrote:
> I'm trying to improve the way Octave behaves when exiting and would like
> to understand what Matlab users might expect.
>
> Does Matlab offer a "confirm before quitting" option for its GUI?

Not sure, but there could be a confirm quit the first time and then a
box "don't ask anymore" to check.


> Does that action work when quit is called from a function, or only when
> it is executed at the command line or when Matlab is closed using some
> "exit applcation" button in the GUI?
>
> If confirmation is requested when the quit function is called from a
> function, what does the quit function do?  Here is an example:
>
>    function myquit ()
>       quit;
>       disp ('foo-i-hithere');
>    end
>
> If you call this function and a quit confirmation dialog is shown and
> quitting is NOT confirmed, does execution continue immediately after the
> call to "quit" so that the message displayed?  Or does execution resume
> at the top-level command prompt with no message displayed?  I'm trying
> to determine whether the quit function interrupts the execution of a
> program (similar to Control-C) even if the quit action is not confirmed.

A few years back I worked hard to make all the 'quit' stuff more
conventional, but it was kind of tricky.  I remember there being a
particular snag, but I can't recall what it is.  I became busy with
other things.  But there is a patch at this bug report:

https://savannah.gnu.org/bugs/?44485#comment44

There is a pretty common convention (and Windows might do this
automatically) of confirming quit and if the application is busy put up
a different type of dialog box like "not responding".  So involved in
this is to tell the core worker thread to exit.  But if the core is busy
computing pi to 5 million decimal places, then a timer in the GUI
expires and asks if the user wants to end that process.  So, then there
is properly shutting down a thread to deal with.  THEN, if the timer
times out and the dialog is visible, say the worker thread finishes its
task and responds to the exit, the dialog should go away and the GUI
exit.  So there needs to be a signal/slot connection from the worker
thread to the "shut-down" dialog.  Also, there could be multiple exit
requests.  As I said, it's tricky.  It's probably dependent on how Qt
signal/slot friendly the overall design is.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Questions about quitting Octave and exit confirmation dialog

siko1056
On 10/29/19 11:10 AM, Daniel J Sebald wrote:
> On 10/28/19 3:38 PM, John W. Eaton wrote:
>> [...]
>>
>> Does Matlab offer a "confirm before quitting" option for its GUI?
>
> Not sure, but there could be a confirm quit the first time and then a
> box "don't ask anymore" to check.
>
>

Dan is right.  For R2019a there is a configuration option explained here

   https://www.mathworks.com/help/matlab/matlab_env/exit-matlab-.html

This configuration options works as described for the GUI and this
"don't ask anymore" appears in each the confirmation dialog.

If Matlab is started by "matlab -nodesktop" the confirmation dialog does
not appear and the configuration is ignored.

>> Does that action work when quit is called from a function, or only
>> when it is executed at the command line or when Matlab is closed using
>> some "exit applcation" button in the GUI?
>>

Same applies command line, script, or function calls "exit" or "quit":
In the GUI a confirmation dialog appears the the configuration option is
set, with "-nodesktop" Matlab immediately quits without confirmation.

>> If confirmation is requested when the quit function is called from a
>> function, what does the quit function do?  Here is an example:
>>
>>    function myquit ()
>>       quit;
>>       disp ('foo-i-hithere');
>>    end
>>
>> If you call this function and a quit confirmation dialog is shown and
>> quitting is NOT confirmed, does execution continue immediately after
>> the call to "quit" so that the message displayed?  Or does execution
>> resume at the top-level command prompt with no message displayed?  I'm
>> trying to determine whether the quit function interrupts the execution
>> of a program (similar to Control-C) even if the quit action is not
>> confirmed.


In your described scenario:
(a) configuration option set
(b) function myquit called from cmd prompt
(c) quit confirmation dlg cancelled

you see the output "foo-i-hithere".  Thus the program execution does not
seem interrupted.  Only the Matlab linter suggests, that the "disp"
statement might not be reachable (no meaning at all).


> A few years back I worked hard to make all the 'quit' stuff more
> conventional, but it was kind of tricky.  I remember there being a
> particular snag, but I can't recall what it is.  I became busy with
> other things.  But there is a patch at this bug report:
>
> https://savannah.gnu.org/bugs/?44485#comment44
>
> There is a pretty common convention (and Windows might do this
> automatically) of confirming quit and if the application is busy put up
> a different type of dialog box like "not responding".  So involved in
> this is to tell the core worker thread to exit.  But if the core is busy
> computing pi to 5 million decimal places, then a timer in the GUI
> expires and asks if the user wants to end that process.  So, then there
> is properly shutting down a thread to deal with.  THEN, if the timer
> times out and the dialog is visible, say the worker thread finishes its
> task and responds to the exit, the dialog should go away and the GUI
> exit.  So there needs to be a signal/slot connection from the worker
> thread to the "shut-down" dialog.  Also, there could be multiple exit
> requests.  As I said, it's tricky.  It's probably dependent on how Qt
> signal/slot friendly the overall design is.
>
> Dan
>

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.

Kai

Reply | Threaded
Open this post in threaded view
|

Re: Questions about quitting Octave and exit confirmation dialog

Daniel Sebald
On 10/29/19 1:13 AM, Kai Torben Ohlhus wrote:
> On 10/29/19 11:10 AM, Daniel J Sebald wrote:
>> On 10/28/19 3:38 PM, John W. Eaton wrote:
>>> [...]
>>>
>>> Does Matlab offer a "confirm before quitting" option for its GUI?
[snip]

>> requests.  As I said, it's tricky.  It's probably dependent on how Qt
>> signal/slot friendly the overall design is.
>>
>> Dan
>>
>
> 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.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Questions about quitting Octave and exit confirmation dialog

John W. Eaton
Administrator
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

Reply | Threaded
Open this post in threaded view
|

Re: Questions about quitting Octave and exit confirmation dialog

Daniel Sebald
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
>>> 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:

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

Dan