On Jan 29, 2012, at 5:35 PM, Paul Johnson wrote:
> On Sun, Jan 29, 2012 at 6:10 AM, Prof Brian Ripley
> <rip...@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@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
