[R-gui] further on the Rcmdr package

[John Fox]

Dear Peter,


At 12:11 AM 5/22/2003 +0200, Peter Dalgaard BSA wrote:
>John Fox <jfox at mcmaster.ca> writes:
>
> > A partly unresolved issue is the problem raised by Dirk Eddelbuettel
> > on Sunday: Dirk found that both the R session and the Commander
> > windows locked up after the Rcmdr package was loaded on his Debian
> > Linux system. Following Dirk's suggestion, I've added an option to
> > Rcmdr to call tkwait until the Commander window is closed. Apparently
> > this solves the problem that Dirk experienced, but an unfortunate
> > consequence is that the command prompt in the R session is disabled
> > until the Commander window is closed. Although this isn't a fatal
> > problem -- commands can still be entered through the GUI, including
> > via the log/script window -- it would be nice to be able to enter
> > commands directly at the command prompt as well. I can do this when
> > the call to tkwait is bypassed on Windows systems and on my Red Hat
> > Linux system. Since no one else reported the problem, I assume that
> > the package also works without the call to tkwait on a number of other
> > systems.
>
>This is definitely not supposed to happen, so perhaps a little session
>with gdb to figure out where things are getting stuck? I do have some
>suspicions about interference between R and threaded Tcl libs, but
>Dirk knows about that.

As I mentioned, I haven't been able to duplicate this problem on my Red Hat 
Linux system and no one else has reported it. I guess that for now I'll 
leave things as they are, allowing tkwait to be invoked as an option.

> > Another, though smaller, unresolved issue has to do with my inability
> > to use the Rcmdr package (or any tcltk-based code) with R under the
> > MDI in Windows. Can anyone tell me what the source of the problem is
> > (that is, why dialog boxes won't stay in front of the R-GUI window)?
> > Is it likely that the problem will be fixed? I actually prefer the
> > SDI, but notice that most of my students like the MDI, which is the
> > default when the Windows distribution of R is installed.
>
>It might be useful to query the Tcl community on that one. Various
>ideas have been suggested, see for instance a search on
>groups.google.com for
>
>   tk Windows "always on top"
>
>Another, more radical idea could be to get the usual MDI code to
>generate a blank window for the Rcmdr, get the hWnd of it somehow and
>then use tktoplevel(....,use=hWnd,....). There are several unknowns in
>that equation, though.

I'll take a look at what Google turns up, as you suggest. I don't think 
that I have the knowledge to mess with the MDI code, I'm afraid.

> > As usual, comments and suggestions are appreciated. I expect that I'll
> > submit a version of the Rcmdr package to CRAN soon.
>
>I played with it briefly. A few random comments:
>
>- Loading packages and installing them from CRAN could be added
>   quite easily (there's a bit of stuff in the tkStartGUI
>   function, which you'd be welcome to lift).

I tried to avoid duplicating functionality in the Windows R-GUI menus. It 
might be useful, however, to provide this facility on non-Windows systems, 
so I'll think about this one.

>- It shouldn't be hard to create a list of loadable datasets and
>   select from it.

I tried that and decided that the list, even with just the minimal packages 
attached, is too long. That's why I settled for generating the list into a 
pager window. Had I not restricted myself to the standard Tk widget 
set  (or perhaps been more imaginative), I might have come up with a better 
solution.

>- Perhaps, use with(dataframe, ...) instead of attach/detach
>   constructs?

It's not hard to do this, and it would be a better solution if users never 
saw the code generated, but one of the objects is to help inexperienced 
users learn the commands, which are echoed to the log window. Again, I'll 
think about this one.

>- It's not easy to find out how to convert variables to factors. If
>   categorical variables come in as numerics, there are lots of things
>   that you cannot do, so the user needs a way to identify and solve
>   the problem quickly.

I had this suggestion from Bob Andersen as well (along with a suggestion to 
provide for reordering factor categories). At present, one could use the 
compute dialog, with as.factor(variable), or the recode dialog. It won't be 
hard to add a "convert numeric to factor" dialog, so I'll put this on the list.

>- The recode syntax is a bit arcane. I think SAS/Analyst does this
>   kind of stuff with a table.

I believe that the problem here is with the help file, which is for the 
recode function in the car package. My general strategy with help buttons 
was to call up existing help files. This was mostly due to laziness, and in 
some cases, such as the recode dialog, it doesn't work very well. I plan to 
write new help files where that seems desirable. I think that it's quite 
easy to enter "recode directives" one per line -- e.g.,

  lo:30 = "low"
  30:50 = "medium"
  50:hi = "high"

There are other formats that the dialog accepts as well. Of course, not 
everyone will agree that this is a natural syntax.

Thank you for your help (and for the great resource that you made available 
in the tcktk package),
  John

-----------------------------------------------------
John Fox
Department of Sociology
McMaster University
Hamilton, Ontario, Canada L8S 4M4
email: jfox at mcmaster.ca
phone: 905-525-9140x23604
web: www.socsci.mcmaster.ca/jfox