Paul E Johnson <pauljohn at ukans.edu> writes:
> When I saw "SciGraphica":
> http://magnet.fsu.edu/~feiguin/scigraphica/screenshots.html
>
> I wished it could be a GUI frontend for R on Unix.
As for R-gnome, it is dormant at the moment. The tcltk interface
somewhat less so (i.e. I hope to have some time to work on it in the
next couple of months).
Personally, I still haven't seen the light, Gnome-wise, and I see some
disturbing tendencies towards "Microsoftish" design principles (with
applications writing undocumented data to undocumented configuration
files, whether or not the user wants it to happen. Not to mention a
horrible number of bugs.).
[I've been trying to use the Gnome desktop since we got the R-Gnome
code, and although some of the stuff is neat and the pictures are
pretty, other aspects are quite maddening. It may well go out the
window soon, to be replaced with something sane like fvwm2.]
However, the choice of GUI toolkit is more or less orthogonal to the
issue of having a plotting interface like the one on those
screenshots. I do sympathize with the desire to have simple and
accessible interfaces like that, but one has to be aware of the
drawbacks. Consider the following R function (somewhat simplified from
the original)
"trace.plot" <-
function(x, y, g){
g <- factor(g)
dfr <- na.omit(data.frame(x=x,y=y,g=g))
dfr <- dfr[order(dfr$g,dfr$x),]
plot(x, y, type="n")
for ( i in levels(g) )
evalq(lines(x,y), subset(dfr,g==i))
}
This plots repeated measurement data for each value of g (typ.
subjects). How would this be represented in a GUI interface? You'll
likely end up with something like
- plot
\_ +box
|_ +axis
|_ +axis
|_ +title
|_ +line
...
|_ +line
|_ +line
|_ +line
with as many line objects as there are subjects in your study. Now
consider changing the color of all those to grey, and compare that to
just adding col="grey" to the lines() command.
OK, one can do better, but not without departing from the plotting
model of R. One could add the notion of scoped graphics parameters for
instance (say - talking off of the top of my head here) and introduce
more intermediate level graphics objects. You might
then have
- plot
\_ +box
|_ +axis
|_ +axis
|_ +title
|_ -line bundle
\_ +settings
|_ +line
|_ +line
|_ +line
|_ +line
This would have some repercussions on the R code that can generate
this type of plot, though. Perhaps something like
graph.obj("line bundle", {
loc.par(col="grey")
for ( i in levels(g) )
evalq(lines(x,y), subset(dfr,g==i))
})
The difficult question is whether something like this can be done
systematically, without reducing the scope of plots that can be made.
Also, there is the "writing in water" aspect of the whole thing: If
you do extensive manipulations of a plot, you get to do the whole
thing again if (when!) a data error is discovered. If you have a
program or script, just rerun it.
The GRZ graphics model on which R and S are based is beginning to show
its age, and at some point one should probably consider improving upon
it. One problem is that in many respects it is a hard act to follow,
because of the number of things it already does right. One thing that
I would probably put higher on my wish list than interactive editing
(which you, BTW, already can do in Windows and on Unix via the xfig()
driver) would be some version of plot linkage - ensuring that plot
elements fit in the plotting area, forcing multiple plots to have
similar axes, etc.
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-help 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: r-help-request at
stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._