Re: What should file-save behavior be like at exit?

[Daniel J Sebald]

On 04/09/2013 06:13 PM, John W. Eaton wrote:
> On 04/09/2013 06:13 PM, Daniel J Sebald wrote:
>
> > Let's go back to this alternate approach I offered the other day. I'm
> > just trying to contrast the differences here and give alternatives or
> > perhaps lead to some enhanced callback approach. Say we have these
> > routines
> >
> > install_octave_command ()
> > corefeval ()
> >
> > from the other day. At the beginning of the GUI/IDE application after
> > launching Octave thread, we could do:
> >
> > install_octave_command ("exit", qt_exit_command);
> > install_octave_command ("quit", qt_exit_command);
> >
> > and the GUI now has control over the exit and can determine exactly when
> > it wants to exit and use a similar if not the exact same exit process
> > for typing "quit" or "exit" at the command line or pressing the X
> > button. For example:
> >
> > qt_exit_command (args)
> > {
> > // Make sure files are saved, everything is happy
> > ignore = some_object->go_through_shutdown_process ();
> > if (! ignore)
> > {
> > corefeval ("exit", varargs, etc.);
> > qApp->quit ();
> > }
> > }
> >
> > Or something like that.
>
> One problem that I see with this approach is that not every
> communication between the GUI and the interpreter is done by a built-in
> function. Or, code in the interpreter could bypass the built-in function
> to perform the same task, so the GUI would never be notified. For
> example, there could be calls to clean_up_and_exit instead of Fquit.

OK, I've grepped the instances:

grep -r clean_up_and_exit *
[snip ChangeLog instances]
libinterp/interpfcn/toplev.cc:              clean_up_and_exit (exit_status);
libinterp/interpfcn/toplev.cc:clean_up_and_exit (int retval)
libinterp/interpfcn/toplev.h:clean_up_and_exit (int);
libinterp/interpfcn/sighandlers.cc:  clean_up_and_exit (0);
libinterp/octave.cc:        clean_up_and_exit (exit_status);
libinterp/octave.cc:        clean_up_and_exit (exit_status);
libinterp/octave.cc:        clean_up_and_exit (parse_status || 
error_state ? 1 : 0);
libinterp/octave.cc:          clean_up_and_exit (error_state ? 1 : 0);
libinterp/octave.cc:  clean_up_and_exit (retval);

It looks like these have to do with either getting a signal (interrupt) 
from the terminal or with processing code at startup.  I suppose there 
could be any number of these calls so long as they happen in 
unconventional ways.  There is always this signal/slot that you utilized 
just recently that indicates that the Octave thread has terminated. 
Maybe the termination is from a segfault within Octave, or this 
clean_up_and_exit occurs unassociated with an "exit" or "quit".  If the 
thread terminates, we could attach that signal to a dialog box with the 
message "Octave has terminated in an unexpected or unconventional way. 
What would you like to do?" and offer the options

o Restart Octave
o Exit
o Continue working
                     OK

That might be better than just exiting the GUI/IDE completely without 
the user explicitly typing "quit" or "exit".

I just tried "Cntrl-C" here in the GUI terminal and nothing happens. 
Typing "Cntrl-C" at the terminal that launched Octave GUI causes the 
command line to advance.  If I run a long process, going back to the 
shell terminal and typing Cntrl-C causes the Octave process inside GUI 
to break out of processing.  I suppose that is a QUnixTerminlImpl.cpp issue.

Dan