Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:
Thomas Vogels <tov@ece.cmu.edu> writes:
Hi,
I've been playing with the tcltk package. It's very nice to have
access to buttons, menus etc. now. Thank you!
Alas, I also have questions: In Tcl everything is a string [*]. This
is not the case in R, of course. So why are return values of tk
commands still strings? (Is there any other reason than speed or
"package is work in progress"?)
The latter. Also to some extent the fact that it requires more
knowledge about the content of the return value. The argument passing
scheme is as you can see quite general and essentially ignorant of the
routines that are called. In essence the issue is that it is fairly
easy to convert whatever to strings, but harder the other way around.
So for the first iteration of the package, the idea would be to have
the user do the necessary as.xxx conversions of return values.
Requiring the user to do the "type casting" will make the user's code
larger and will make it harder to adopt the package. It would be nice
if the information would "flow more easily" to the programmer. I
don't want to have to use more as.whatever than I have to in other
functions.
One problem is that the number of functions just explodes, so it might
be better to wrap them into one enchillada?
> tkwinfo <- function (widget, what="exists", ...)
switch (what,
exists=tkcmd("winfo", "exists", widget)=="1",
ismapped=tkcmd("winfo", "ismapped", widget)=="1",
width=as.numeric (tkcmd("winfo", "width", widget)),
height=as.numeric (tkcmd("winfo", "height", widget)),
tkcmd ("winfo", what, widget, ...))
(The other problem is that tkcmd("winfo",...) may fail.)
OK, instead of going for enchilladas, how about burritos:
For a graphics device, I would use
> par("xaxp") # to obtain values
[1] 2 10 4
> par (xaxp=c(2,10,4)) # to set values
Wouldn't something similar to this effect simplify the api and reduce
the number of commands in the package (vastly)?
1) Why not
> tt<-tktoplevel()
> button <- tkbutton(tt, text="Push", command=function()cat("Ouch\n"))
> tkpar (button, c("text", "command"))
$text
[1] "Push"
$command
[1] " R_call 0xbfeb1c "
> tkpar (button, text="Yow!", command=function()cat("Yow\n"))
instead of:
> tkcget (button, "-text") # (hmm, shouldn't need '-' here!)
[1] "b"
> tkcget (button, "-command") # (again, why '-command'?)
[1] " R_call 0xbfeb1c "
> tkconfigure (button, text="Yow!", command=function()cat("Yow\n"))
[1] ""
> # Doesn't return previous value...
This examples applies to a bunch of command pairs, like
cget/configure, itemcget/itemconfigure, imagecget/imageconfigure,
entrycget/entryconfigure, window.cget/window.configure, ...
2) Why not:
> tt <- tktoplevel()
> tkwm (tt, "minwidth") # returns integers not strings
[1] 1 1
> tkwm (tt, minwidth=c(100,100)) # sets new values
instead of:
> tkwm.minsize (tt)
[1] "1 1"
> tkwm.minsize (tt, "100","100")
[1] ""
The second example would wipe out 25 or so tkwm.* commands to be
replaced by one tkwm. (Same would apply for tkwinfo...) Wouldn't
that also simplify maintenance and documentation?
Does this make sense? Or does it sound like I've been smoking my corn
flakes instead of eating them? Is anybody else using the package
tcltk and would it make sense to put some code behind those
suggestions?
Thanks,
-tom
Oh, while I'm at it: There is no tkupdate:
> tkupdate <- function (idletasks=FALSE)
if (idletasks) tkcmd ("update", "idletasks") else tkcmd ("update")
(which is essential to making sure that a window is mapped before its
width or height is queried.) That's trivial if you have hacked Tcl/Tk
before -- so who is the package tlctk aimed at?
Tcl/Tk hackers of course, the author of the package not being one...
Basically, the plan is to add stuff as it becomes necessary to do
useful things, so feedback and suggestions from developers are always
welcome.
--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907
mailto:tov@ece.cmu.edu (Tom Vogels) Tel: (412) 268-6638 FAX: -3204
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._