[RkWard-devel] plot.function and curve

[Thomas Friedrichsmeier]

On Friday 02 February 2007 20:20, Prasenjit Kapat wrote:
> a) somehow prevent the xlim from being evaluated unless both the
> entries are valid.

This should be the case in SVN since Thursday. Also, it would probably be a 
good thing to add some sort of status bar to the preview window, so it's 
easier to see, whether the preview is currently up to date, or not. Also, 
probably some checkbox like "keep preview" would be nice.
Something for after 0.4.6, though.

> OR
> b) preset the the xlim values based on the current plot parameters
> (par("usr")). But this options is not good. Querying par("usr") opens
> up a empty X11 device, if none exist.
>
> Basically, the broader idea is to show the user the current par()
> values when plot_options is used. Then let the user change them if
> he/she feels so. We can put an "advanced" tab in plot_options for
> doing this!

Unfortunately, both is not quite trivial in the current design. The problem 
is, that there are really three different "stages" in the plugins:
1) user changes settings in the GUI
2) the PHP template is evaluated asynchronously (but typically very near 
real-time)
3a) when the user presses submit - or -
3b) when the preview code has changed, the generated R code is evaluated, 
again asynchronously (and this may take longer, see below)
So it would be difficult to feed back results from R commands into the GUI.

Note: In some much earlier version of RKWard, there was support for directly 
evaluating R commands (and handling the results) from within the PHP code - 
so this is certainly possible, in theory. However, the problem is that you 
can't ever be sure, when an R command get's run (there may be other commands 
waiting to finish, first, and also due to the threading and thread switching 
involved, there will always be a delay between placing an R command, and 
seeing the result of at least a few milliseconds. This does not apply to the 
speed at which R commands can be evaluated (internally, they are placed in a 
queue, and can be evaluated in quick succession), but only to the "response 
latency", so to speak. However, this would mean, each single call to R from 
PHP will take - at least - a few ms, since there, the result would have to be 
returned before the template can proceed). For those reasons, I decided to 
removed that feature again, and figured "let's try, whether we really need 
something like this, first".

Something like what you describe would probably be useful to have, indeed. But 
probably there's no real good way to do it from PHP - so it will either have 
to be that "more flexible scripting, I'm dreaming about", or C++.

> Anyway, I guess all this is just food for thought in the long run.

Yes, due to the design implications, I'd rather not rush any particular 
solution, here.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070204/73ee4312/attachment.sig>