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

[Philippe Grosjean]

Hello,

Related to Windows installer changes (requests), would it be possible to 
specify whether RGui is installed to run in MDI or SDI mode at start? It 
is as simple as adding a 'Run RGui in SDI mode' option in InnoSetup that 
installs a <Rdir>/etc/Rconsole file containing 'MDI = no' when the 
option is checked.

Explanation: MDI mode is an old-style and it is less in use now (most 
recent multidocuments programs offer either navigation with tabs, and/or 
SDI mode to manipulate multiple documents; even Microsoft that used the 
MDI style in all its applications is now moving to SDI with Word, Excel, 
...). Regarding R, the MDI-style in RGui is problematic, or at least 
suboptimal, with many GUIs under Windows.

Currently, new users that are told to switch to "SDI style in RGui" are 
very intimidated by the procedure: (1) what is SDI versus MDI?, (2) they 
have to open the 'RGui preference' dialog box, make the changes, save 
the file in a particular location, (3) ignore the intimidating warning 
that appears, (4) close RGui and restart it. All this is very, very 
unfriendly for a very first approach to R... and I see it on the face of 
my students!

With the option in InnoSetup installer, everything would be much 
smoother to get RGui in SDI mode from start.

Thanks for considering this proposition.
Best,

Philippe Grosjean

..............................................<°}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Belgium
( ( ( ( (
..............................................................

Prof Brian Ripley wrote:
> On Tue, 4 Jul 2006, Duncan Murdoch wrote:
> 
> 
>>On 7/4/2006 11:57 AM, Uwe Ligges wrote:
>>
>>>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).
>>>>
>>>>    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!
>>>>
>>>>    Duncan> I haven't made any change to the Mac GUI to support this.  On
>>>>    Duncan> Unix-alikes, the text prompt should respect this option.
>>>>
>>>>    Duncan> The other change is to the Windows installer, to
>>>>    Duncan> allow the user to choose whether to set
>>>>    Duncan> quit.with.no.save, MDI/SDI display, and help style
>>>>    Duncan> at install time.  The only (intentional) change to
>>>>    Duncan> the current behaviour is to default to CHM help
>>>>    Duncan> instead of plain text.
>>>>
>>>>People have asked me in private about this, and I didn't know
>>>>the answer:
>>>>Is it true that this means that people can no longer commit the
>>>>"cheap package install trick" on Windows for  R-code-only
>>>>packages?
>>>>Namely
>>>>  1) install a source package on a Linux/Unix/MacOSX machine
>>>>     (where it is often simple to have all the necessary tools available)
>>>>  2) zip the resulting installed package
>>>>  3) unzip it on the target Windows machine into the corresponding
>>>>     library (directory).
>>>>
>>>>Of course, this trick will not provide any *.chm help files.
>>>>Will the cheap-installed package still work, using the *.txt (or
>>>>*.html) help files?
>>>
>>>
>>>
>>>Well, the user has to ask
>>>    help(topic, chmhelp = FALSE)
>>>in this case, or (s)he get the message:
>>>
>>>              No CHM help for 'foo' in package 'pkg' is available:
>>>      the CHM file for the package is missing
>>>
>>>Perhaps it is possible to arrange some fallback to plain text help if
>>>chmhelp is not available: in print.help_files_with_topic call print() on
>>>the "help_files_with_topic" object again, but change attribute "type" to
>>>"help" before that call ...
>>
>>Yes, that seems to work.  I'll add that.
> 
> 
> Before help() was reorganized to use print() methods it used to fall back 
> to text help if other versions were not available (at least on Windows), 
> so it does seem sensible to reinstate that.
> 
> Brian
>