[Rd] tk non-widget commands (esp. update and winfo)

[Thomas Vogels]

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._