[R-gui] OpenOffice.org and R

Philippe Grosjean phgrosjean at sciviews.org
Thu Feb 24 14:59:52 CET 2005


Just a little comment on what Daniele Medri said:

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

I agree that tk is a little outdated: many widgets and features missing. 
However, it works with R quite good through the tcltk package. There is 
also tile, a project to "revitalize tk widgets". I make tcltk2, a R 
package to enhance tk widgets in R using tile and others. However, I 
develop it under Windows, and there is still a little work to do to make 
sure it compiles and works on all supported platforms.

Otherwise, svDialog in the SciViews bundle is designed in a way that it 
is independent from particular widgets. There is a demonstration of the 
same dialog boxes implemented either in tk, or in wxWidgets (using James 
Wettenhall R-wxPythyon package). The problem is: R-wxPython is still 
experimental and incomplete, and James does not seems to have time 
enough to continue its development.

For the rest, one thing I know: I *hate* the look-and-feel of Gtk under 
Windows.

Best,

PhG


Daniele Medri wrote:
> 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



More information about the R-SIG-GUI mailing list