1

In developing a gWidgets interface to plotting data and model results, I create a plot page and with par(mfrow=c(4,1)) to put 4 plots stacked up.

The first plot (a simple y vs. x on the top) works fine, but the remaining 3 plots in the loop create axes but plot no data. To test the code, I tried opening a new plot window before looping through the plots, and all worked fine.

Is there something in gwdigets interaction with plot(...) that would be useful to know?

EDIT a reproducible example:

doesn't work:

library(gWidgets)
options(guiToolkit="RGtk2") ## "Qt"
w <- gwindow("brush example", visible=FALSE)
g <- ggroup(container=w)
gg <- ggraphics(container=g)

addHandlerChanged(gg, handler=function(h,...) {
  par(mfrow=c(2,2))
  plot(mpg ~ wt, mtcars)
  plot(mpg ~ wt, mtcars,col='blue')
  plot(mpg ~ wt, mtcars,col='red')
  plot(mpg ~ wt, mtcars,col='green')
})
visible(w) <- TRUE

should look like this (normal R graphics window:

enter image description here

Not like this

enter image description here

Dr Dave
  • 453
  • 1
  • 4
  • 11
  • 1
    Can you provide some example code? Please read this: http://stackoverflow.com/questions/5963269/how-to-make-a-great-r-reproducible-example – Dason Feb 12 '13 at 17:12
  • @Dason I add a reproducible example. – agstudy Feb 12 '13 at 17:55
  • This is almost exactly the problem I'm having. The first plot is good, the rest, no data. In my case, the y-axis ticks are missing but the numbers are there instead of the x-axis. – Dr Dave Feb 12 '13 at 18:13
  • It looks like the problem crops up when the plots are created in a handler rather than directly in the code. Examples in code box above. – Dr Dave Feb 12 '13 at 18:26

2 Answers2

1

For some reasons the plot can't be refreshed. You can ou can use multiple ggraphics instances or maybe you can use ggraphicsnotebook .

Here a solution using many instances of ggraphics.

library(gWidgets)
options(guiToolkit="RGtk2") ## "Qt"
w <- gwindow("brush example", visible=FALSE)
gg <- ggroup(container=w,horizontal=F,use.scrollwindow = T)
down.group <- ggroup(container = gg)
up.group <- ggroup(container = gg)

devs.up <- lapply(1:2, function(i) 
                 ggraphics(container=down.group,label=as.character(i)))
devs.down <- lapply(3:4, function(i) 
                 ggraphics(container=up.group,label=as.character(i)))
visible(w) <- TRUE
lapply(c(devs.up,devs.down), function(gg)
addHandlerChanged(gg, handler=function(h,...) {
  par(mfrow=c(1,1))
  plot(mpg ~ wt, mtcars)
}))
agstudy
  • 119,832
  • 17
  • 199
  • 261
1

There are two issues. One might be related to the cairo implementation on windows. This can be tested by avoiding gWidgets altogether:

make_plot <- function() {
  par(mfrow=c(2,2))
  plot(mpg ~ wt, mtcars)
  plot(mpg ~ wt, mtcars,col='blue')
  plot(mpg ~ wt, mtcars,col='red')
  plot(mpg ~ wt, mtcars,col='green')
}

require(RGtk2)
require(cairoDevice)

w <- gtkWindow(show=FALSE)
da <- gtkDrawingArea()
w$add(da)
w$show(TRUE)

asCairoDevice(da)

make_plot()

The other issue is putting the graphics drawing call inside the handler. For ggraphics, the change handler is called after one finishes rubber banding, not when the graphic itself changes. Not sure this is the most useful thing, but is meant to call some handler after a selection is made through rubber banding. The addHandlerClicked might be of more interest.

jverzani
  • 5,600
  • 2
  • 21
  • 17
  • I test your code... I have to change `w$show(TRUE)` to `w$visible <- TRUE`...But I still get the same bug.. I am in windows. – agstudy Feb 12 '13 at 18:49
  • Oops. That issue rests with cairoDevice, and likely farther downstream with libcairo as it seems to only happen with windows. I don't really have a great workaround. You could try showing the graphic in a `gimage` container, but getting that to resize isn't working for me. – jverzani Feb 12 '13 at 19:54
  • Thank you...Sorry for asking here but I see that in SO few persons answers questions about `gWidgets`. Does Shiny is a good alternative? – agstudy Feb 12 '13 at 19:59
  • If you are doing web GUIs, shiny is a great alternative to the gWidgetsWWW2 things. It is a different programming paradigm, but people seem to like it. While very nice, and easy to distribute, these web GUIs aren't as feature rich as their desktop counterparts. For example, editable grids require some additional work and I haven't seen people using tree widgets, though possibly they have. – jverzani Feb 12 '13 at 21:18