(G)UI for R and in R
Thomas Vogels <email@example.com>
Mon, 15 Nov 1999 15:47:01 -0500
I've followed the discussions about the object explorer thingy et
al. last week. I'll add below my thoughts about what a GUI could do
and how it could be done. This matrix shows along which "axes" I think
to evaluate how R will fit into my tool box in the future. It may or
may not be interesting for the developers on this list -- I was just a
bit confused about what some people want and how they get there.
I'm _not_ asking for answers for the questions below. (I can easily
find out that a solution to R+CGI is Rweb.) I'm interested in whether
I forgot some major idea or realization path...
Usage -- what are the interfaces for?
1) for data input or exchange
Can I drop my data from a spread sheet into R? Can I get results
back into a (spreadsheet) application? Can I request data from a database?
dto. with "high-level" constructs in R? Can I call R from a CGI
script? Can another application "drive" my R session?
2) for help with writing R scripts
Does R help me with a graphical introspection tool? I guess this
is what the object explorer is meant for. Can I bring up a list of
objects and kinda click my way to the attributes of the object? its
data? (Not unusual scenario: And why does apply not work this time?
Oh, wrong dimensions, I forgot the "drop=F" option...) Can I click on
a function and send it to an editor? Find out where it came from?
3) for "clients"
Can I package an R program so that others aren't stuck with a
static analysis of the data? Can I add menus/options/etc. so that
others can twiddle my view of the data (possibly without understanding
R)? Sometimes, this is very simple stuff, like maybe somebody would
rather see relative than abs. frequency. Why not give them a button
and a plot device instead of a static picture?
How -- what are my options to program an interface?
1/2) approaches for data import/export - stuff I've seen mentioned is use
of CORBA, SQL, DCOM, other D&D protocols. Yes, they all do different
things, but the underlying question is: Why do I export my data to
file to then call read.table in R? Why doesn't R just "know" about my
data? Could I mark a table in another program, then go to my R prompt
and say "new.data <- import.from.selection ()"? If I can attach
data.frames, why not a data base?
Also, who is in the driver's seat? In option 1 it's R where R
queries for data. In option 2 it's another application that ask R to
perform services (calculations, model fitting, etc.) on its behalf.
3) "low-level" approach for the GUI part - use a system dependent
library (like X, Xt, Gnome and the Windows equivalents). This hurts
if you move between platforms. It also means lots of code and need
for a compiler. I actually also put the Java solutions here -- Java
helps to stay (mostly) platform-independent but is low-level in its
approach to UI programming. This may be different if you rely on
Swing or other GUI classes. If you don't, you'll have to write a
decent amount of code.
4) "high-level" approach for the GUI part - I'd put scripting
languages here. Actually, the tcl/tk interface wasn't mentioned last
week but appears, at least to me, to be a promising approach. You
can piece an interface together rather quickly in tcl/tk and you don't
have to touch a compiler.
5) "high-level" approach to GUI but with R commands - I don't like 1
and only "kind of" 2 because they require me to go outside of R. I'd
like to program a menubar (with a help entry), some buttons, multiple
canvases (each e.g. an X11 device and a frame around with a button
"send to printer"), with R functions. (Of course, I see that this in
turn goes back to either 1 or 2. But only once for the authors of the
Option 5 goes into the direction of a visual R - I don't want to
write a for loop to calculate the mean of a data vector. I want to
say "mean(v)". Along the same line, I want to say
fam.select <- choice (title="Link function", c("gaussian", "poisson"),
glm (..., family=query(fam.select), ...)
This gives the user a menu, allowing him/her to influence
calculations. And I don't have to think about radio buttions or
geometry managers or whatever.
But then, would this be part of R or do you want to keep stuff like
mailto:firstname.lastname@example.org (Tom Vogels) Tel: (412) 268-6638 FAX: -3204
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: email@example.com