R devel - Sep 2015 - issues with dev.new avoiding RStudio plot device on unix?

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 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

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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

> 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.
But not if running from RStudio always causes the X11 check to fail.  If the
function is used outside RStudio, there's little point in specifying
noRStudioGD=TRUE in the first place.

If you consider the code used to determine whether quartz() or X11() is
available

	dsp <- Sys.getenv("DISPLAY")
	if (.Platform$OS.type == "windows")
		windows
	else if (.Platform$GUI == "AQUA" || ((!nzchar(dsp) ||
grepl("^/tmp/launch-", dsp)) && .Call(C_makeQuartzDefault)))
		quartz
	else if (nzchar(dsp) && .Platform$GUI %in% c("X11",
"Tk"))
		X11
	else defdev 

you can see that it checks for a DISPLAY variable and assumes that X11 can be
used if it is set.  Wouldn't it be just as safe to add RStudio to the list
of accepted .Platform$GUIs?

In my case (Mac OS X 10.10.5), I'd like to get a quartz device.  The problem
here is that I have XQuartz installed, so DISPLAY is always set and looks like
this

	/private/tmp/com.apple.launchd.2wKas4wzPe/org.macosforge.xquartz:0 

while dev.new() checks for ^/tmp/launch-; I suppose the DISPLAY variable has
changed between different versions of Mac OS X or XQuartz.  Perhaps the
additional patterns could just be added to the grepl() call?

Best,
Stefan