[Rd] tcltk GUIs (was need gui matrix editor: does R Core team have advice on how?)

Simon Urbanek simon.urbanek at r-project.org
Mon Jan 30 03:39:16 CET 2012


On Jan 29, 2012, at 5:35 PM, Paul Johnson wrote:

> On Sun, Jan 29, 2012 at 6:10 AM, Prof Brian Ripley
> <ripley at stats.ox.ac.uk> wrote:
>> On 28/01/2012 22:04, John Fox wrote:
>>> 
>>> Dear Paul and Gabor,
>>> 
>>> The Rcmdr GUI uses the tcltk package, so I have some experience with
>>> providing an R tcltk-based GUI for various platforms.
>>> 
>>> As Gabor says, everything works very smoothly on Windows because the R
>>> Windows binary includes Tcl/Tk.
>> 
>> 
>> Maybe, but getting it there was very far from smooth.  Tcl/Tk compiled under
>> the compilers we used, but the resulting DLLs crashed R.  No one has ever
>> found the cause and I used the system SDK (essentiallly a version of VC++)
>> to build them.  And that puts us in a bind since the current system SDKs
>> generate code depending on DLLs that are not part of the minimal OS versions
>> we support (e.g. Windows XP and Server 2003, and the machine used to build
>> was retired 2 years ago).
>> 
> 
> Thanks, this is clearing things up. I believe these comments mean
> that, at the current time, tcl/tk is as close as there is to an
> officially endorsed graphical toolkit.  As I search more, I find many
> other community contributors (besides Prof. Fox) using tcl/tk
> (Sciviews).  So I should learn how to work with that.  Prof Ripley's
> comment makes me think the endorsement is not entirely enthusiastic,
> though.
> 

I can certainly second that (but I may be biased by having to deal with its infelicities - I would also prefer to have a working native toolkit in the binary distribution). Tcl/Tk is not a graphical toolkit, it is a language that happens to support some kind of graphical interface but I would certainly not recommend it as a GUI toolkit. My interpretation is that its presence in R is purely historical (it was an option that someone wrote code for at the time). That said, given the lack of choices, a lot of code was based on it. Now with the advent of packages, you have the choice - there are many toolkits you can choose from now.

This is just my $0.02, not an "official" endorsement ;).

Cheers,
Simon



> If there were a change to emphasize Gtk2, I don't think I would be
> disappointed. I've been testing table-making examples today.  On
> Debian Linux, I am having more luck with the Gtk2 based packages.
> dfedit in RGtk2Extras "just works" for me. Example:
> 
>> library(RGtk2Extras)
>> mat <- matrix(rnorm(100), 10, 10)
>> dfedit(mat)
> 
> That edits the R object mat as expected.
> 
> On the other hand, I don't have success with the tk2edit from tcltk2,
> even with the example in the help page:
> 
>> library(tcltk2)
> Loading required package: tcltk
> Loading Tcl/Tk interface ... done
>> ?tk2edit
>>  data(iris)
>>     tk2edit(iris)
> Error in matrix("", nrow = nrow(tA), ncol = ncol(tA)) :
>  non-numeric matrix extent
> 
> I've fiddled with this quite a bit, I believe there's some little
> mismatch between this particular system's tcl/tk libraries and the
> ones that tcltk2 is expecting. Packaging of tcl/tk has caused lots of
> trouble with Swarm simulations that we run, maybe that's breaking
> tktable usage too.   I'm going to look into that some more.
> 
> I think the idea behind gWidgetstcltk is great, it aims to create R
> functions that can use either Gtk2 or tclk.  But the implementation is
> a big hassle, it seems to me.  It inherits all of the management
> troubles of both tcltk and Gtk2. For example.
> 
>> library(gWidgetstcltk)
>> mat <- matrix(rnorm(100), 10 , 10)
>> gdf(mat)
> Select a GUI toolkit
> 
> 1: gWidgetsRGtk2
> 2: gWidgetstcltk
> 
> Selection: 2
> guiWidget of type: NULL for toolkit: guiWidgetsToolkittcltk
> Warning message:
> In .gdf(toolkit, items = items, name = name, do.subset = do.subset,  :
>  Container is not correct. No NULL containers possible
> 
> When I run the example at the end of the help from ?gdf in
> gWidgetstcltk, I get this (even before trying to use the table at
> all).
> 
>>   obj[,] <- head(mtcars) ## replace df
> Error in `.leftBracket<-`(`*tmp*`, toolkit, ..., value = list(mpg = c(21,  :
>  Value has different number of rows than the replacement area
> 
> If I make the other selection, opting for Gtk2, I don't get an error,
> but nothing happens--no table pops up either.
> 
>> library(gWidgetstcltk)
>> mat <- matrix(100, 10, 10)
>> gdf(mat)
> Select a GUI toolkit
> 
> 1: gWidgetsRGtk2
> 2: gWidgetstcltk
> 
> Selection: 1
> Loading required package: gWidgetsRGtk2
> guiWidget of type: gGridRGtk for toolkit: guiWidgetsToolkitRGtk2
> 
> If I had not seen the Gtk2 table work well with RGtk2Extras, I'd have
> no faith at all.
> 
> In conclusion, what am I supposed to work on?
> 
> If tcl/tk is likely to stay in the R for Windows package, then we can
> work on streamlining the Macintosh and Windows instructions for tcltk
> maintenance, then I see my mission now is to make TkTable based
> widgets work.   Right?
> 
> Something Prof. Grothendieck said made me curious.  One can package
> the TkTable library with an R package?  Why is it not already included
> in packages like tcltk2 or gWidgetstcltk?
> 
> Debian package libtktable2.9 installs these files:
> 
> /usr/lib/Tktable2.9/libTktable2.9.so
> /usr/lib/Tktable2.9/pkgIndex.tcl
> /usr/lib/Tktable2.9/tkTable.tcl
> 
> So TkTable requries not just the tcl bit, but a shared library. Is
> that a substantial roadblock to R packaging of TkTable? (I've never
> tried it).
> 
> pj
> -- 
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 



More information about the R-devel mailing list