Re: [rkward-devel] altering rk.graph.on and rk.graph.off
On Wed, Sep 1, 2010 at 12:21 PM, Thomas Friedrichsmeier 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
Hi, On Wed, Sep 1, 2010 at 12:02 PM, Thomas Friedrichsmeier 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
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. > > I'll refrain from tinkering with that part of the code! Let Thomas come > > back. I'm a bit reluctant for two reasons: 1) We should try to focus a bit on finishing and polishing all the new features, in order to get ready for the next release. That's not to stop you from implementing new features, but perhaps keep any non-trivial new features as patches for a while, instead of committing to trunk (*). 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. Regards Thomas (*): Probably it makes sense to create a branch in SVN in a while, and then trunk will be open to larger changes, again. signature.asc Description: This is a digitally signed message part. -- 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, 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? 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) Regards Thomas signature.asc Description: This is a digitally signed message part. -- 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
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 Stefan,
On Mon, Aug 30, 2010 at 8:23 PM, Stefan Rödiger 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. 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.
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.)
I'll refrain from tinkering with that part of the code! Let Thomas come back.
> 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.
--
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
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
