What should file-save behavior be like at exit?

[Daniel J Sebald]

This post related to the callback discussion of a few days ago.

On 04/09/2013 04:25 AM, Daniel J Sebald wrote:
> On 04/09/2013 03:52 AM, Daniel J Sebald wrote:
>
> main_window::prepare_to_exit (void)
> {
> +fprintf(stderr,"Need to save edited files here as well. Should be easy.
> Issue close to all the file_editor_tabs somehow.\n");
> write_settings ();
> }
>
> Actually, that's not a good place for such a thing. (The
> "write_settings" that main_window does is just stuff related to the main
> window. So it makes sense to have that here.)
>
> Instead, closing edited files should probably be done best inside the
> destructor for the file_editor_tabs. I.e., put a closeEvent or something
> more direct at the start of file_editor_tab::~file_editor_tab. When the
> application destruction is done, it should eventually get around to
> calling every file_editor_tab's destructor.
>
> I'm going to create a bug report.

Hmm, I started looking at this file save problem.  I thought it would be 
something easy, but it turns out to be rather convoluted, plus there 
might be a problem with flow so I don't know if I want to attempt a 
solution that won't be satisfactory.  Here are some observations:

1) Currently, the only way to initiate the dialog box that asks to save 
modified files is to close via the tab close.  This is a proper thing to 
do, but to initiate such a thing one would need a routine to go through 
the file list and call the file_editor_tab close routine.  That's not a 
big problem.  Note, however, that we really don't want to close the tab 
(i.e., don't want to remove it from the editor because it won't be 
opened at the next startup), the file should be saved before exiting the 
GUI/IDE.

2) That last issue in #1 wouldn't be too hard to address.  There is an 
option "remove_on_success" which I could figure out how to access. 
There is no avoiding such a distinction though.  The "ask file save" 
dialog should be pretty much the same for closing via tab X or via 
application X button.  In one case the tab is removed from the editor, 
in the other case it is not removed from the editor.

3) Now, there are some ramifications with #2, which entail how file-save 
behavior should be at exit.  Right now the dialog gives options

CANCEL | NO | YES

"Yes" will save the file and close the tab.  "No" will discard changes 
and close the tab.  "Cancel" will do nothing and NOT close the tab.

OK, how should this play out at exit?  I guess my preference as a user 
would be "Yes" will save the file and exit the app.  "No" will discard 
changes and exit the app. "Cancel" will not do anything and NOT exit the 
app.  That is the way many common editors behave.  However, with the 
current setup, I think the best that can be done is the "No" and "Yes", 
but there is no way to "Cancel" and not exit the application.  Should we 
remove the cancel button in that case?  That just seems like too much 
work-around to end up with an inelegant solution.

4) There are some issues with dialog boxes at application exit.  In that 
case they should probably be Modal because after showing the dialog, the 
app will be closing.  The modal/nonmodal is a small issue.  One can 
always change appropriately.  Anyway, the nice way for this to behave on 
the GUI/IDE side is that pressing the main_window X button initiates a 
closeEvent().  The main_window closeEvent() should (i.e., currently 
doesn't do this) in turn issue similar events to all the 
file_editor_tab.  If one of those file_editor_tabs indicates the event 
should be "ignored" (i.e., the user selects "Cancel"), then main_window 
indicates it wants to "ignore" the event, and the application will NOT 
close.

5) Here's where the problem lies:

void
main_window::closeEvent (QCloseEvent *e)
{
  e->ignore ();
  octave_link::post_event (this, &main_window::exit_callback);
}

As I described in #4, the main_window can "ignore" (done here) which 
means the application will not close immediately.  Instead, the 
termination of the application is handed over to Octave core.  Octave 
core terminates and does a callback which initiates the qApp->quit(). 
This is currently done so that "exit" and "quit" at the Octave command 
line, as well as pressing the X button or "close" from the menu will all 
exit the application.

However, I think this is the wrong flow.  It means that once the user 
selects "close" from the main menu, or presses the X button of the main 
menu, the Octave core is going to terminate no matter the scenario.  So 
there is no way a Dialog box could ask to save a modified file and not 
exit the application if the user presses Cancel.  Octave core is going 
to terminate regardless.  In addition, pressing the X button when Octave 
is busy doing some long calculation is not elegant.  The app does 
nothing until Octave finishes, and then the GUI disappears.  That is 
just not a good way for the GUI/IDE to respond.

6) OK, what is preferred?  Well, it seems to me that ultimately closing 
the application should remain the responsibility of the GUI/IDE.  It is 
sort of the main thread in this setup.  If the user presses the X button 
and some circumstances arise where the user didn't want to exit because 
of unsaved files, or Octave processing, or whatever, then Octave inside 
the terminal window should remain active.  What would also be nice is if 
the user presses X button and Octave is busy running, the GUI should 
throw up a Dialog box saying "Octave is busy processing.  Do you really 
want to exit before the process is complete?".  That, like the file-save 
Dialog (i.e., the user) could end up ignoring the close request and not 
want to terminate Octave.

Can the callback approach be made to work?  We want pressing the X 
button and typing "quit" at the Octave terminal command line to create 
the same behavior at exit.  But again, we aren't 100% that Octave and 
GUI/IDE will necessarily want to quit in either of those cases under the 
scenario of an IDE.  That is, even if the user types "exit" at the 
command line, it doesn't necessarily mean that anymore.

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.

Dan