[Rd] options("quit.with.no.save"), and Windows installer changes

[Duncan Murdoch]

On 7/4/2006 12:02 PM, Simon Urbanek wrote:
> On Jul 4, 2006, at 11:15 AM, Martin Maechler wrote:
> 
>>>>>>> "Duncan" == Duncan Murdoch <murdoch at stats.uwo.ca>
>>>>>>>     on Tue, 04 Jul 2006 08:32:08 -0400 writes:
>>
>>     Duncan> I've just committed a couple of changes to R-devel  
>> related to requests
>>     Duncan> at userR about the Windows installer.  The first of  
>> these affects all
>>     Duncan> platforms, but I've only tested it on Windows:
>>
>>     Duncan> I added an option "quit.with.no.save".  If TRUE,
>>     Duncan> then the default q("ask") prompt will not offer to
>>     Duncan> save the workspace.  This is in response to the
>>     Duncan> observation that new users who are instructed not to
>>     Duncan> save their workspace, get confused when they
>>     Duncan> accidentally answer Yes to the prompt to save it.
>>
>> Ok...  but I probably misunderstand a bit:
>>
>> The default has not been   q(save = "ask") but  q(save = "default"),
>> and that default has depended on startup.
>>
>> Even now, "R --no-save"  already did have the desired effect,
>> on Unix at least.  For my ESS setup, I have made this an automatic
>> default many months ago.
>>
>> Wouldn't it be easier and sufficient to make "--no-save" a working  
>> option on all platforms ?
>> Or is the point really about changing the quitting dialog?
>> For me quitting *without* a dialog is the most important thing  
>> which I use (often several times a day).
>>
> 
> I agree - it would be even nicer if there was a way to enable --no- 
> save with some environment variable ...

Environment variables in Windows are a mess.  Doing things on the 
command line or through option() is a lot easier.

> However, I think Duncan's approach is a very bad idea, because it  
> means that with the same answer will give you opposite result. This  
> is a big UI no-no. (Windows users may may think it's a valid option,  
> because Microsoft tends to do stupid things like that, but that's  
> only because they never think about UI).

I agree that that is a problem.  However, I don't know a better solution:
   - I want to make it hard for the user to accidentally create a saved 
workspace.  Just changing the default will mean that people who 
habitually answer "yes" will still get the wrong result.
   - I want to make it hard for the user to accidentally lose a 
workspace.  Hence --no-save is not an option.

The problem with my solution as it stands is that people who habitually 
answer "yes" will sometimes accidentally lose a workspace.

> The correct approach is to change the default button, but definitely  
> not the dialog box.

I don't think this is sufficient.

> Speaking of default buttons - is there a specific reason why hitting  
> <Enter> at the prompt is not a valid answer in the console? It would  
> be nice to have let's say Enter=y, ^D=no, ^C=cancel (the last one  
> works already).
> In the Mac GUI the behavior is well-defined and compatible with all  
> Mac applications (Enter=Save, Esc=Cancel, Cmd+D=Don's save) - doesn't  
> Windows define something system-wide like that?
> 
> BTW: back to the original issue that Duncan raised - isn't the actual  
> problem rather the fact that once you saved an image you cannot get  
> rid of it? Unless you know the "internals", namely that it's a file  
> named .RData, you can't discard it. There is no way to say "discard  
> saved workspace". Maybe that's what should be addressed instead...

That's a good idea.  Or perhaps instead of quit.with.no.save, we want 
start.with.no.load, i.e. something like the --no-restore option.

Duncan Murdoch

> 
> 
>>     Duncan> I'm not sure about the wording of the user prompt
>>     Duncan> question, which is now "Quit and discard
>>     Duncan> workspace?".  The problem with this wording is that
>>     Duncan> someone who automatically hits "y" will lose their
>>     Duncan> work.  I've tried on Windows to make the dialog box
>>     Duncan> look different enough that they should be warned.
>>
>> good!
>>
> 
> Since when do people read text in dialog boxes ;)? Especially those  
> that have been there for ages ;).
> 
> Cheers,
> Simon