How graphical an interface should the default be?

On Feb 25, 2005, at 3:11 AM, Prof Brian Ripley wrote:

install/update.packages will have a lot of changes in 2.1.0, and I have 
been adding some widgets to go along with this.

- Rather than just CRAN and BIOC, you have a character vector of
  repositories.  There is a function setRepositories() to set the
  appropriate option().

- There is no default CRAN, but a function chooseCRANmirror() to set a
  mirror, which is invoked if you try to access CRAN without setting a
  mirror.

- update.packages(ask="graphics") brings up a listbox for you to de-select
  packages (all available updates are pre-selected).

- install.packages() with no/empty pkgs argument brings up a listbox of
  all available packages (including those inside bundles).

- menu(graphics=TRUE) is implemented.

These can be set up to use widgets where available (Windows, if Tk is 
available under X11, I hope Aqua before release), and have a text-mode 
fallback (better than the current menu(), but in that spirit). (Except that 
is install.packages: text-mode selection from 480 packages even in three 
columns is not useful to me, but a scrolling list works well as Windows 
users of R already know.)

My question is:

	What should be default be?

Options might be:

- use the graphics widget if available.

- make the graphics the default on Windows (it will always be available,
  but not necessarily on the right screen under DCOM uses).

- make text-mode the default on Unix.

- do different things for different tools.  Currently setRepositories()
  and chooseCRANmirror() default to graphics-if-possible, and
  update.packages() defaults to text mode (which gives more
  detailed information).

I am not really in favour of making the defaults a set of options, but that 
is possible.


This is a request for input on what would be a good compromise for general 
R users (and not just the R-devel audience).

Hi,
Thanks for taking this on - it looks like a big step forward. I have some 
pretty minor comments/questions. We will, of course, try to adapt the BioC 
code in time...

We probably want to be sure that any function calling one of these has 
complete control and can override user defined defaults.

args(chooseCRANmirror)

I am not completely clear on your model for how the repositories are 
searched though. Two questions come to mind: 1) How do I get the most recent 
version of a package, regardless of which repository it is in?

2) Can a package from one repository have its dependencies resolved in 
another repository, or not?

(this last one is a real can of worms - in my view, as one might really 
prefer a same repository solution, but that means that repositories 
might need to completely contain CRAN - which is clearly less 
desirable). And of course this may be too fine a level of detail, but 
these problems have come up in our experience.

I think it would be nice if getting dependencies had two (or more 
levels), so that I could get only those packages that the current 
package "Depends" on, and a second level where I could get both the 
"Suggests" and the "Depends". For me (at least) Suggests is weaker, and 
for many users the "Suggests" set of packages is not always needed - the 
"Depends" set, is though. Currently the dependencies option seems to 
only allow TRUE and FALSE.