[rkward-devel] updateHistoryActions and rInterface ()->issueCommand

[Thomas Friedrichsmeier]

Hi,

On Sunday 04 July 2010, Prasenjit Kapat wrote:
> A question regarding the following function  (or nextPlot() or
> firstPlot() or ...) in rkwindowcatcher.cpp.

I'll in a somewhat different order:
- I think the only safe assumption regarding the state of the history is that 
the R code knows the "true" state of the history at all times, while the code 
in RKWard does not. This will become even more relevant once you implement 
history length/size limits. But also, sine rk.next.plot() and friends are 
publicly visible, we should assume people might use them from R, directly, 
even though it will be used via the tool-buttons *most* of the time.
- The calls to updateHistoryActions() in the C++ code really are not very 
important for that reason. In adding them, I was thinking about the corner 
case where R is still busy (or replaying the plot takes a considerable amount 
of time). Here the idea was to give a graphical indication immediately, while 
.rk.graph.history.gui() will not be called immediately. And it was easy to 
do... Of course if this is not always correct, as you write, then maybe it is 
not worth doing.
(Side note: The C++-code also only takes care of updating the actions in the 
current device, while - if history length changes - all devices will need to 
be updated).

> Does it matter if updateHistoryActions (...) is called before or after
> calling RKGlobals::rInterface ()->issueCommand (...)?

Technically, no. Commands run asynchronously, and while you can never tell 
whether the command will get run immediately or later, RKWard will not see 
anything about that command (including the callback from 
.rk.graph.history.gui()) until the next iteration of the event loop. Thus, 
putting updateHistoryActions() after issueCommand() would not make a 
difference. But since updateHistoryActions() *will* happen first, it makes sense 
to place it first for readability. I see that I did not do so, consistently.

> If the R command (in the variable 'c') changes the length of the
> history then, is the updateHistoryAction (....) call aware (or
> unaware) of this change? I think it is not!

It is not, or at least only in some cases (for instance when clearing the 
history, we know that the new length (and position) will be 0, so in 
clearHistory() we have updateHistoryActions (0, 0).

> I was trying to avoid calling .rk.graph.history.gui () from the replay
> (...) function (ie comment line 179 in public_graphics.R of rev. 2930)
> and hoping that the (uncommented) updateHistoryActions (...) calls
> would take care of the job. 

Again, I think the only safe assumption is that the R code is in charge of the 
history, not the other way around.

> But, in a situation where the current plot
> is unsaved and the user clicks the "previous" button, although
> recordUnsaved () does save this plot, the updated history length (one
> more plot was added) does not get passed on to
> RKCaughtX11Window::previousPlot. As a result the updateHistoryActions
> () call still uses the old history_length value (which is one less
> than the updated length). And hence a little chaos.

I had not thought of that case. I guess it's hard to tell whether this will 
happen from the C++ code. Thus, perhaps it's really best to simply remove 
those calls to updateHistoryActions(), and let .rk.graph.history.gui() take 
care of it.

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/20100704/7b5548f7/attachment.sig>