[rkward-devel] altering rk.graph.on and rk.graph.off

[Prasenjit Kapat]

Hi,

On Wed, Sep 1, 2010 at 12:02 PM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> Hi,
>
> On Saturday 28 August 2010, Prasenjit Kapat wrote:
>> I've modified the rk.graph.on () and rk.graph.off () functions
>> slightly in trunk. Since many might be using these functions (as it is
>> used in a lot of plugins), here is a little explanation:
>
> yes, I think this is a good idea, indeed!
>
> I wonder whether the "set.active.device" parameter is actually needed,
> however. I see you use set.active.device=FALSE, for the copy to output action.
> But isn't the net effect the same as the default set.active.device=TRUE? The
> only difference I can see is that the graphics window to be copied is not
> activated in this case. But then why not? Most other interactions with a
> graphics window lead to activation, too, and why shouldn't they?

Well, in implementing the plot history actions, I've always reset the
active device to whatever was before the action was called. My view is
this: The user can have one screen device active (for plotting) and
can browse the plot history on another screen device. None of the
browsing actions should change the active device.

But then, "Copy to output" is not really a browsing action, so yes, we
can set it as active. I've cleaned up the code. I was actually in two
minds while implementing it.

> Note that
>  dev.set (non.current.device.number)
> will open a new device. This could cause confusion in the (unlikely) case that
> the previous device was closed in between calls to rk.graph.on() and
> rk.graph.off(). So I'd suggest to re-write the line rk.graph.off() as
>  if ((!is.null (i)) && (i %in% dev.list ()) dev.set (i)

Yes, this is precisely what I did after replying to Stefan yesterday.

Regards,
-- 
Prasenjit