On 7/4/2006 12:02 PM, Simon Urbanek wrote: > On Jul 4, 2006, at 11:15 AM, Martin Maechler wrote: > >>>>>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> >>>>>>> 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel