[R-gui] Re: R-SIG-GUI digest, Vol 1 #18 - 5 msgs

[Philippe Grosjean]

Peter Dalgaard wrote:

>[...]; the only really sticky issues
>that I see are associated with the intertwining of event loops,
>issuing a locator() call while retaining the ability to navigate
>menus, etc. and they are sticky whichever way you turn the interface.
>I suspect that there's not going to be a neat solution of that without
>some form of multithreading. [There are issues even without an actual
>GUI, just try something like "boxplot(1:10); help(boxplot)" under X11
>and notice that the plot doesn't redraw until you terminate the help
>pager.]

Yes, yes, yes, for SciViews this is the major reason why I am actually
looking for an alternate solution. Believe me, I hate to reinvent the wheel.
I hate to recode tkTable (or even tkPlot, or so...), but they simply do not
operate as required in SciViews for now! It is because in SciViews I have
two separate processes (in fact three, not counting the separate threads,
but I do not detail for now): one for R, the other one for the GUI. R - GUI
communication is asynchronous. It means that the GUI is _never_ blocked by
R. I know that for the moment, all this is fuzzy because I still haven't
released any code. It is is preparation and I plan to release something
before March 2003. Patience. Patience.

However, I would gladly reconsider my position at a later time, if somebody
proposes a workaround for these problems. Indeed, I feel a little
incomfortable to be in the position of rejecting what is already done with
the tcltk package and the like. I feel also incomfortable in using a
propretary and platform dependent alternative (Windows OCXes). However, my
major concern for the moment is to finalize a working prototype that could
demontrate the original approach in SciViews, as soon as possible. So, I
cannot wait until these little problems are solved, and I really have no
time to work on them myself.


>The basic thing to avoid is the "ESS approach" (don't get me wrong,
>some of my best friends are ESS users ;-) ) where the interface must
>try to learn about the internal state of R by parsing printed output
>(and then make the command and its output disappear from the eyes of
>the end user). There needs to be a direct interface at the level of
>the language objects.

??? OK, I see why (questions of performances, mainly?). However, SciViews
uses ESS mode. It is very convenient for some tasks. Just an example: I call
an enhanced args() that automatically gets arguments of a functions in a
tooltip as soon as I type "(" after the function name. I know, there are
some problematic issues in R with generic methods. It was already discussed.
It is not solved yet. But anyway. The point is that using the ESS mode, and
sending something like "enhanced.args(my function)\n", and retrieving the
result does the job perfectly well for most functions. Direct access to R
objects could be more efficent... Just sticking to efficiency is an
incomplete view of the problem. There is a pretty nice aspect in the ESS
mode: it makes abstraction of the way the calculation kernel operates
internally as much as possible. You just have to change a little bit the
command string to do exactly the same in Octave, Matlab,... In SciViews, we
need a solution that works for R, but also for Octave, Scilab, Matlab,
Splus, Ox,... and more. So, do not eliminate ESS mode too rapidly!

By the way, it is for the same reason that I encourage Thomas' initiative to
propose an abstracted plugin-definition language.

Otherwise, I agree that _most_ commands should not become transparent to the
user. In particular, filling a dialog box should not result in transparent
issuing of commands (like in Splus, for instance). Dialog boxes should just
serve as a help to generate R code for occasional users that are not very
familiar with the underlying language.

Philippe

...........]<(({?<...............<?}))><...............................
( ( ( ( (
 ) ) ) ) )      Philippe Grosjean
( ( ( ( (
 ) ) ) ) )      IFREMER Nantes - DEL/AO
( ( ( ( (       rue de l'Ile d'Yeu, BP 21105, 44311 Nantes Cedex 3
 ) ) ) ) )      tel: (33) 02.40.37.42.29, fax: (33) 02.40.37.42.41
( ( ( ( ( 
 ) ) ) ) )      SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (       e-mail: phgrosjean@sciviews.org
 ) ) ) ) ) 
( ( ( ( (       "I'm 100% confident that p is between 0 and 1"
 ) ) ) ) )                                L. Gonick & W. Smith (1993)
.......................................................................