[R-gui] OpenOffice.org and R

[Daniele Medri]

Dears,

Alle 11:16, giovedì 24 febbraio 2005, Philippe Grosjean ha scritto:
[cut]
> Other ways where interaction between R and OpenOffice could be interesting:
>
> 1) Using oOOCalc as a powerful replacement of the data editor in R:
> function edit(mydataframe) opens the dataframe in oOOCalc and changes
> made are transmitted back to R.

Probably, these are things that could be a warm-up stage before something more 
powerfull. oOO calc has widgets for that I suppose.

> 2) Using oOOWriter as a "notebook à la Mathematica" editor, that is,
> mixing plain text with calculations and graphs interactively generated by
> R.

Personally, I don't like this way... but with a <component> that link R to oOO 
could be "easy" open a terminal like console with R <somewhere> in OOwriter 
to do that.

> 3) Using oOOWriter as a report editor (see for instance the reporting
> features in the SciViews bundle on CRAN).

very nice!

> 4) Using oOOWriter as a WYSIWYG help files (.Rd) editor.

IMHO the features is "have help file write-able with any editor", the way to 
write these is a user choice. Yes, WYSIWYG could help a bit.. :)

> Now, regarding the way you make R and oOO collaborate, there are again
> many possibilities. Besides the shared library under Unix, and the
> R.dll, or R(D)Com server in Windows, I think the optimal communication
> would:
> - require no changes in R, and no recompilation,

good.

> - be bidirectional,

good.

> - allow communication with R even when it is busy calculating something
> (in the case you can interact with R both at the command line and with
> the external client simultaneously),

I don't know exactly what you mean, but I am thinking about <something> like 
SAS server-client do with many processes-threads. IMHO this is a powerfull 
features that could trasform R in a killer app for companies that have data 
on servers and analyst with clients. Probably this point contrast with first 
point, either if R has/hasn't this capability.

Following this way, could be very good to collaborate with a database project 
team like Postgresql (for example). Many apps have connection with this 
software (eg. GIS) and actually exist a PL/R too.

With the same interest could be GNUe project, a free software ERP that already 
have an applications server ready.

> - allow connecting/disconnecting (hot plug) to a running R session that
> was not started initially to interact with your client application,

an application server.. look at GNUe -www.gnue.org

> - work the same way on all supported platforms.

good.

> Clearly, solutions proposed in
> http://cran.r-project.org/doc/manuals/R-exts.html#Linking-GUIs-and-other-fr
>ont_002dends-to-R do not match one or several items in this wishlist. Also,
> all of them use R as a server exclusively, that is, you cannot interact
> with R as usual at the command line at the same time you plug it into you
> client (well, you have to program your own console window in the client app
> to get a control of R through command line). Indeed, there are
> circumstances where you would prefer to keep both a direct and indirect
> interaction with R. Options 1, 2 and 4 above  may fall in this category.
>
> With Tom Short (the author of Rpad), we have started exploring the
> possibilities to use sockets by means of Tcl. Tcl (tcltk R package) is
> now widely usable with R, and it is possible to write a very powerful
> socket server with this language. You will find a first implementation
> of it in svSocket package (part of the SciViews bundle), and also a more
> advanced one to exchange HTML data in Rpad. I think this is a promising
> approach because it matches all items in the wishlist: it works the same
> on all platforms; it permits hot plug no mather the way R was started
> (console, Rgui under Windows, Emacs-ESS, ...), etc.

are you working with wxWidgets too?
Tcltk is a reality, but widgets are not so good, not so beauty.

> Finally, I would say that I am willing to help in your entreprise. If
> you decide to use part or all of the R GUI API I am implementing in the
> SciViews bundle, I can surely help you to use it (documentation is only
> partial for the moment). I can also add, or adapt functions of this API
> to make it more efficient in the context of your developments for oOO.

..your proposal is a good way to follow and, IMHO all could appreciate the 
existance of ideas and real solutions.

>From an analyst/user point of view (that use Sciviews+R / SAS on windows, or R 
terminal either on win/linux) I found all these ideas good, but not *enough*.
IMHO, I could be very-very happy with:

1. On R front,  start R as a server to handle multiple connection from 
R-client through unix socket or tcp/ip. This feature should be part of 
r-project directly. Many free software implementation has this already done 
and could be an "easy" port.

2. On oOO front, have an additional application that share db widgets with the 
new access-like app, share spreadsheet widget with Calc for data entry and 
could communicate with R-server as a client, either locally and remotly for 
datas. On oOO front, this new app should be a diagram editor like SAS 
Enterprise Miner or SPSS Clementine, with code editing capabilities and a 
terminal like console to R, good enough for the oOO target of users. These 
features should be part of oOO project.

Again: what kind of widgets/toolkits? I found Gtk the best choice in terms of 
quality, "freely" available, multi-platform. Novell is working hard to extend 
windows support too, and this is very good.

RECAP

talk about with R-core team about "server" feature,
talk about with oOO team for a new app in analysis direction.


bye
-- 
Daniele Medri - http://www.medri.org

"There is a risk that data analysts will see patterns that are merely a
result of looking too hard. Under torture, the data readily yield false
confessions."