[rkward-devel] Request for feedback on plot history

[Thomas Friedrichsmeier]

Hi,

On Thursday 02 September 2010, Prasenjit Kapat wrote:
> On Wed, Sep 1, 2010 at 4:31 PM, Thomas Friedrichsmeier
> 
> <thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> > Is it really a good idea to synchronize the plot windows that show the
> > same history position? I.e. if two separate windows each show the first
> > plot in history, and that is removed, should the other window really
> > switch to the next plot, too? Or should that now be considered a "fresh"
> > plot?
> > 
> > I could see the merit in both, but the current behavior was somewhat
> > surprising to me at first.
> 
> Yeah, that was something on my mind too, but let us stick with this
> for now. It can be changed to something more "intuitive" later.
> 
> In any case, the way I look at it is this: what you are removing is a
> plot from the history not just from the displayed device. I'll take a
> note of this and we can come back after 0.5.4.

Yes, ok.

> > Should dev.set() always set newPlotExists for the respective device to
> > true? In case additions are made to that plot? E.g. produce a plot, add
> > it to history, then add a grid to that plot, then use previous / next
> > actions -> grid is gone.
> 
> Yes, that is an inherent problem with all the secondary base graphics
> functions: points, lines, abline, mtext, grid, title, axes, ....
> We would not, as of current implementation, know when such a function
> was called. At this stage the user should click the "+" button to save
> (overwrite and not append) the plot manually.

Yes, I realized that after writing the mail. We simply have no chance to 
detect all such changes to existing plots in a fully realiable way.

What I find unsatisfying about the current solution is that it's not really 
obvious when a plot will be recorded automatically, and when it will not be 
recorded automatically. I think the answer is it is recorded *the first time* 
we switch to another plot in any way (plot.new(), new device, prev/next 
buttons), but never again after that. I think this is simply very unintuitive, 
and can easily lead to annoying surprises.

Ok, but then what?

Here's two ideas:
1) *Never* save to the history automatically, but only when the user clicks 
"+". The advantage of this solution is that there are no surprises. But it 
also takes away some of the usefulness of the plot history. Still it might be 
worth to offer this as an optional behavior (but perhaps not for the moment, to 
avoid adding too much complexity too soon)?

2) *Always* save to the history on plot.new, prev/next, etc. without the whole 
newPlotExists mechanism. The advantage is again that it offers much less 
potential for surprises. It does seem pretty wasteful, since most of the time, 
the plots are not actually modified, but we still record them again and again 
while browsing the history. On the other hand, recording plots appears to be 
pretty damn fast for anything that I have tried so far, while replaying plots 
is inherently slow. So any overhead that we add at this point will probably 
not be noticeable.
Follow-up problem: Synchronization is probably needed in case of multiple 
device windows showing the same history position (this time potentially 
wasting a lot of CPU cycles, since it can mean a slow replay-operation; but 
then this case should only be triggered every once in a while).

Well, I think 2) will be worth a try.

(BTW, these may have implications for the behavior of the "+"-button, too. For 
solution 1, probably the current "replace plot" behavior makes most sense. For 
solution 2, "replace plot" is rather useless, and so it should really be 
"insert plot".)

> Letting dev.set () always set newPlotExists to TRUE will force
> recording with each and every arrow movement
> (first/previous/next/last). I am a little reluctant in doing this. How
> much of an overload would that be? Would the "browsing" feel sluggish?
> May be not, I'll give it a try.

So basically I'm suggesting the same thing, but the newPlotExists mechanism 
would then be obsolete, as far as I can see.
 
> One thing that I had in mind was to use the assignInNamespace trick
> for _all_ of these secondary functions; although it may work only for
> some and not all of them. But this approach seems kind of brute force!

Yes, and it's asking for breakage, sooner or later. At latest, when a new 
secondary function is added.

> > Probably makes more sense to add this info in a drop-down list of plots
> > in the history (your point c). For the plot that is currently shown,
> > info on titles, etc. is not really interesting. It is interesting for
> > browsing the plots which are *not* currently visible, however. I can try
> > to add something, but I'm not sure how soon.
> 
> Precisely. I just wanted to have a stub which can be used later. If
> you so prefer, I can comment out the entire "info" codes for this
> release.

I think it does not do any harm to keep it as is for now. Only the "info" 
button should be less visible for the release, IMO.

> > Toolbar is crowded. I'd suggest to remove first/last plot, remove plot,
> > clear history, and info buttons from the toolbar by default.
> 
> I would like to keep "remove plot" on the toolbar, others can go, no
> problem ;)

Ok.

> > Could you check the code for parts which are no longer needed and remove
> > those? .verify.history.limits() appears to be one unused function.
> 
> I'll check these. The verify.hist.limits () fn is used in
> settings/rksettingsmoduleoutput.cpp ~199

I see. Sorry for the false alarm.

Oh, and just to keep it on the record: Automated tests, once things look 
stable.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20100902/bd41cf58/attachment.sig>