On 29/09/2015 2:00 PM, Skye Bender-deMoll wrote: > > > On 09/26/2015 03:22 AM, Duncan Murdoch wrote: >> On 26/09/2015 1:42 AM, Skye Bender-deMoll wrote: >>> Sorry, should have given more background. x11 works fine on all my >>> systems when called by x11(). I'm the maintainer of a package that uses >>> the animation library, which has performance issues when used with the >>> RStudio plot device. But if you call plot.new() when using RStudio, you >>> get an RStudio device, not the standard device for the platform because >>> it overrides the device option. So I've had to have the library do >>> platform detection and platform-specific device calls, which R CMD check >>> doesn't like. I believe that noRStudioGD argument was avoided to give >>> users a way around this, but it doesn't seem to be behaving correctly in >>> the unix interactive case. >> >> It seems like the best workaround here could come from RStudio. They >> could provide a way for a user to indicate that they sometimes don't >> want to use the RStudio graphics device (e.g. an option setting), and >> your package could set and restore this option around your dev.new() call. > > That would make sense, I've tried to propose they add it as a feature in > the rstudioapi. However, since the noRstudioGD option now exists in R, > I'd think it should behave consistently across platforms? Opening pdf > on one and interactive on another seems odd.
The problem is that the device chosen by dev.new() depends on the GUI. You can see the code that does this in grDevices:::.onLoad. So in fact with noRstudioGD=TRUE, the decision is identical to what it is in R: you only get X11 if your GUI is X11 or Tk, you get pdf otherwise. It's pretty common to use R on a machine where X11 won't work, so this makes sense. Now "RStudio" is common enough nowadays as a GUI so perhaps it should be added to the list in both places, but I'm not sure that would work when RStudio is running on a server rather than on the local machine. I think the RStudio people would have to make sure this worked, and if they're doing that, wouldn't it be easier for them to provide the option themselves? Duncan Murdoch >> >> The other seems to be for your package to temporarily set >> R_DEFAULT_DEVICE if the user doesn't already have it set, and use >> noRStudioGD=TRUE. The disadvantage of this is that you need to do all >> the platform-based decision making. > > Great idea, I'll employ this workaround for now. Thanks! > > best, > -skye > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
