Re: [rkward-devel] altering rk.graph.on and rk.graph.off
Hi, On Wed, Sep 1, 2010 at 12:02 PM, Thomas Friedrichsmeier thomas.friedrichsme...@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 -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] altering rk.graph.on and rk.graph.off
On Wed, Sep 1, 2010 at 12:21 PM, Thomas Friedrichsmeier thomas.friedrichsme...@ruhr-uni-bochum.de wrote: Hi, On Tuesday 31 August 2010, Stefan Rödiger wrote: Am Dienstag 31 August 2010, 05:54:41 schrieb Prasenjit Kapat: I am guessing it should be easy to do, without the syntax highlighting. Looking at plugin/rkstandardcomponentgui.cpp, just sending code_property-Preprocess () + code_property-calculate () + code_property-printout () to .rk.cat.output () would do it. Of course, a button on the GUI somewhere. go for it ;) The button action will be more appropriate on the plugin dialog box rather than on the screen device window. (All though, I have arguments in favor of device window as well.) why not both (at least for testing)? well, it will be a good deal more difficult to add in the screen device window, since it is hard or even impossible to track which commands were used to create that plot. True, for a preview-window we could get that information from the plugin, somehow, but in fact even a preview window could be modified from the command- line, and we'd have no chance to track the code for those changes. So I don't think that can be done in a reasonable way. 2) This is not really limited to plots. Copying the R code to the output is interesting for any plugin. And in fact this is not really limited to plugins, either. On the users' list, Augustin Lobo asked for an option to carbon-copy R commands from the console/script windows to the output. Therefore it may make sense to implement this at a more central place. E.g. a global option / button to turn transcription of R commands into the output window on / off. We may need to toy with some ideas, here, but in any case I think this is probably something for 0.5.5, rather than 0.5.4. Fair enough. This, if done at the right place, will be a great feature. Regards, -- Prasenjit -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] altering rk.graph.on and rk.graph.off
Am Dienstag 31 August 2010, 05:54:41 schrieb Prasenjit Kapat:
Hi Stefan,
On Mon, Aug 30, 2010 at 8:23 PM, Stefan Rödiger stefan_roedi...@gmx.de
wrote:
Hi Prasenjit,
I simply love the stuff you do. Never thought of it, now I won't miss it.
It is so convenient, smart and useful.
Thanks ;) I wish it was implemented in a better by R. Consider this
example (nothing to do with rkward:
# print device list and the currently active device:
f - function () {print (dev.list ()); print (dev.cur ())}
x11 ()
f ()
plot (0,0)
png (file = tmpplot_dev3.png, width = 400)
f ()
plot (rnorm (100), rnorm (100))
pdf (file = tmpplot_dev4.pdf, width = 4)
f ()
dev.off () # closed pdf, x11 is now active !!
f ()
dev.off () # closes x11!! png is now active
f ()
dev.off () # closes png, FINALLY!
The problem, is that dev.prev () and dev.next () are implemented in a
cyclical numeric order. In this sense,
dev.off (which = dev.prev ())
might make more sense, than, the currently implemented:
dev.off (which = dev.next ())
yet, the main problem would persist.
But in implementing a linked list of active devices would pose some
logical problems (what happens if you close the previously active
device as opposed to closing the current device?), and hence, I think,
the simplistic dev.prev and dev.next exists. In that sense, my fix
is buggy. Hmm...
Thomas asked for feedback some weeks ago which I will try to address
later.
See if you can use the latest svn code.
One stupid question. Right now it is possible to copy the preview plot to
the output. I wonder if it is possible to embed the corresponding code
too (since the user might be used to that in RKWard behaviour in
RKWard)?
Nice idea.
glad to hear
I am guessing it should be easy to do, without the syntax
highlighting. Looking at plugin/rkstandardcomponentgui.cpp, just
sending code_property-Preprocess () + code_property-calculate () +
code_property-printout () to .rk.cat.output () would do it. Of
course, a button on the GUI somewhere.
go for it ;)
The button action will be more appropriate on the plugin dialog box
rather than on the screen device window. (All though, I have arguments
in favor of device window as well.)
why not both (at least for testing)?
I'll refrain from tinkering with that part of the code! Let Thomas come
back.
okay
Regards
Stefan
Am Samstag 28 August 2010, 03:22:44 schrieb Prasenjit Kapat:
Hi,
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:
As you may know, in R, after dev.off () closes the current device,
dev.next () is set as active. This applies to RKWard as well. But,
when
rk.graph.on (); ; rk.graph.off (); # dev.off () is called inside
rk.graph.off ()
is executed (in some form or the other), dev.next () is not
necessarily the device that was active before rk.graph.on () was
called. This creates a little confusion (at least to me, see [1]
below) especially when copying a device to output via Device Copy
device to output. Hence the fix.
For those following the trunk, let me know if you see any regressions
or non-intuitive behavior. Of course, this only affects rk.graph.on
and rk.graph.off and DOES NOT alter the usual (R's) behavior of
dev.off ().
Regards,
--
Prasenjit
[1]
x11 ()
plot (0,0)
x11 ()
plot (1:10,1:10)
dev.copy (device = rk.graph.on); rk.graph.off ()
dev.off (); # closes the wrong device, w/o the fix.
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] altering rk.graph.on and rk.graph.off
Hi Prasenjit, I simply love the stuff you do. Never thought of it, now I won't miss it. It is so convenient, smart and useful. Thomas asked for feedback some weeks ago which I will try to address later. One stupid question. Right now it is possible to copy the preview plot to the output. I wonder if it is possible to embed the corresponding code too (since the user might be used to that in RKWard behaviour in RKWard)? Regards Stefan Am Samstag 28 August 2010, 03:22:44 schrieb Prasenjit Kapat: Hi, 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: As you may know, in R, after dev.off () closes the current device, dev.next () is set as active. This applies to RKWard as well. But, when rk.graph.on (); ; rk.graph.off (); # dev.off () is called inside rk.graph.off () is executed (in some form or the other), dev.next () is not necessarily the device that was active before rk.graph.on () was called. This creates a little confusion (at least to me, see [1] below) especially when copying a device to output via Device Copy device to output. Hence the fix. For those following the trunk, let me know if you see any regressions or non-intuitive behavior. Of course, this only affects rk.graph.on and rk.graph.off and DOES NOT alter the usual (R's) behavior of dev.off (). Regards, -- Prasenjit [1] x11 () plot (0,0) x11 () plot (1:10,1:10) dev.copy (device = rk.graph.on); rk.graph.off () dev.off (); # closes the wrong device, w/o the fix. --- --- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] altering rk.graph.on and rk.graph.off
Hi, 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: As you may know, in R, after dev.off () closes the current device, dev.next () is set as active. This applies to RKWard as well. But, when rk.graph.on (); ; rk.graph.off (); # dev.off () is called inside rk.graph.off () is executed (in some form or the other), dev.next () is not necessarily the device that was active before rk.graph.on () was called. This creates a little confusion (at least to me, see [1] below) especially when copying a device to output via Device Copy device to output. Hence the fix. For those following the trunk, let me know if you see any regressions or non-intuitive behavior. Of course, this only affects rk.graph.on and rk.graph.off and DOES NOT alter the usual (R's) behavior of dev.off (). Regards, -- Prasenjit [1] x11 () plot (0,0) x11 () plot (1:10,1:10) dev.copy (device = rk.graph.on); rk.graph.off () dev.off (); # closes the wrong device, w/o the fix. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
