Hi,
On Tue, Sep 7, 2010 at 5:04 AM, Thomas Friedrichsmeier
<thomas.friedrichsme...@ruhr-uni-bochum.de> wrote:
> On Tuesday 07 September 2010, Prasenjit Kapat wrote:
>>
>> C. a STATIC global switch (checkbox) to enable / disable the plot
>> history feature. STATIC means: "toggling the checkbox will only affect
>> new sessions of rkward, not the running ones"
>> - this global switch should be used to enable/disable the menu/toolbar
>> actions as well
>
> Just an idea, haven't thought this through: Wouldn't it be enough to disable
> the record()-function (and clear any existing history) in order to effectively
> turn off the whole history? That could easily be switchable at runtime, then.
It has to be taken care off in rk.screen.device () (onAddDevice ()),
dev.off () (onDelDevice ()) as well. Additionally, switching, should
clear and re-initiate the variables properly. Let me see which is
easier.
>> 2. duplicating a device:
>> - behave as if the duplicated plot is "new" ie do not alter the old plot
>> - when/if, possible to determine (reliably) that this "new" duplicated
>> plot and old plot (duplicated from) are identical, do not save this
>> new plot, otherwise always add it to the history at a new position
>
> I'd say the second bullet can safely be neglected for an initial
> implementation. Then no special treatment should be needed for dev.copy() at
> all, as it will simply behave like any other new plot.
You are right, let me ignore it for this version. With a reliable
remove action, the user can delete the duplicated plot manually.
>> 3. multiple plots on the screen:
>> - check for par (mfig) and graphics:::.SSexists ("sp.screens")
>
> While certainly desirable, this can probably be ignored for an intial
> implementation as well, IMO.
OK.
>> 4. save the history list when rkward closes - not for this release
>> - as part of the "save workspace"?
>> - Windows uses .GlobalEnv::.savedPlots right from the beginning
>> - when loading, replace the existing plot history by the loaded one?
>
> Agreed, not for this release. For any R objects in the workspace, the policy
> is to remove those, and then add the new ones. So I guess the existing plot
> history would be replaced in this case, too.
Not for this release, right.
>> 5. Actions:
>> a. first / prev / next / last
>> b. remove plot (has to be implemented due to 1.)
>> c. append plot
>> d. insert plot
>> e. overwrite/replace plot (insert then remove)
>
> Insert, then remove would certainly do the trick, but also it could have side-
> effects of popping plots from history. So perhaps a separate treatment might
> make sense after all.
>
> As long as "append plot" exists, "insert plot" can probably wait, too. So if
> insert seems complex, I suggest ignoring it for now.
Good. I'll try to focus on "append plot" only for now then.
>> 5a. first / prev / next / last
>
> (and plot.new()/dev.off())
Right.
>> 5b. remove plot
>> - if the user removes a plot from a device then replay the "next
>> available" plot on this device
>
> Add a special case when the plot is automatically removed due to history
> length restriction. In this case, the current device does not show the removed
> plot (but rather the one to be saved), and does not need to replay anything.
Yes.
>> [*1]
>> use either identical (a,b) or identical (a[[1]], b[[1]])
>
> Are you sure the raw vector is not needed for comparison? But in fact, I could
> not find a counter-example so far.
Well, not finding a counter-example does not prove the theory, for
sure ;) So, yeah I am not sure either.
But, for this release, we can ignore the subtleties and stick with (a,b)
With that said, here is a difference in behavior, that we should resolve:
Situation 1:
Suppose device 2 displays plot (1,1) and it is saved at position 10 in
the history. Duplicate device 2 to device 3. Now plot (1,1) on device
3 is set as "new". Update this using, say, a title () call. Now, this
plot will get appended to the history (even w/o the update). Position
10, remains unaltered.
Situation 2:
Suppose both devices 2 and 3 are displaying the same position, say,
10, which is plot (1,1). Update the plot on device 3, by, say, a title
() call. At this stage, should the plot on device 3 be set as "new" or
should the one on device 2 be set as "new." In the former case, the
behavior is similar to situation 1 and the "new" plot from device 3
will be appended to the history. While in the later case, the updated
plot on device 3 gets saved at position 10 ("overwrite" type of
behavior), unlike situation 1, but the unaltered plot from device 2
gets appended to history.
So, the issue is this: in situation 1, the altered plot is appended to
the history while in situation 2, the unaltered plot is appended to
the history.
Shouldn't the behavior be consistent in both situations? If so, which
(of the two cases in situation 2) is more intuitive (or less
confusing)? Of course, in situation 1, we could set the plot on device
2 as "new" instead of the one on device 3 to match up with the later
case in situation 2.
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
