[Rd] tk non-widget commands (esp. update and winfo)
Peter Dalgaard BSA
10 Feb 2001 02:50:13 +0100
Thomas Vogels <email@example.com> writes:
> > 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
Sure, but it requires more detailed study of what the query-type
functions do, and what values they return.
> > > 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
>  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"))
>  "Push"
>  " R_call 0xbfeb1c "
> > tkpar (button, text="Yow!", command=function()cat("Yow\n"))
> instead of:
> > tkcget (button, "-text") # (hmm, shouldn't need '-' here!)
>  "b"
> > tkcget (button, "-command") # (again, why '-command'?)
>  " R_call 0xbfeb1c "
Actually, I think tkcget(button, text=NULL) is the convention for
argument-less options. The " R_call 0xbfeb1c " is wrong in either
case: It really should return the R object sitting at the address
0xbfeb1c, reversing .Tcl.callback.
Not sure that I would want to go the tkpar() route. If I were moving
away from the direct correspondence between the R and Tcl side of the
fence I'd probably rather overload the $ $<- [[ [[<- set of operators
and have stuff like
and so forth. I sort of started along a similar path with the
tktitle()/tktitle()<- mechanism, but stopped as it seemed to be
getting excessive to complete this mechanism for all commands.
> > tkconfigure (button, text="Yow!", command=function()cat("Yow\n"))
>  ""
> > # 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
> > tkwm (tt, minwidth=c(100,100)) # sets new values
> instead of:
> > tkwm.minsize (tt)
>  "1 1"
> > tkwm.minsize (tt, "100","100")
>  ""
> 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?
Nope. I'm not necessarily saying that it might not be a good idea, but
introducing command-dependent option handling is not going to simplify
the documentation. Explaining why tkwm (tt, minsize=c(100,100))
doesn't come across as "wm .1 -minsize 100 100" but as "wm minsize .1
100 100" would be tricky to explain. In this case, the changed syntax
doesn't actually save you anything anyway.
> 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
We have the occasional report from people using the package. My guess
is that it gets used for fairly simplistic things similar to the
demos. In a slightly longer perspective, I'd like to see a more
elaborate user interface prototype emerge from it. The package
certainly needs further development, and in particular the return
value handling needs some sort of fixing up.
I still think it is useful to keep some sort of unifying perspective
on the whole thing, and I do think it is useful - at least for now -
to try and maintain some of the transparency between the R functions
and the corresponding Tcl commands.
If you want to start writing code, it might be useful to attack the
cget-style functions first. It might be nice if they could vector to a
(say) tkquery function which could be supplied with a table of return
types by option.
One possible gotcha is that the list of options is really widget
specific, and I'm not quite sure that it cannot happen that the same
option name corresponds to different value types in different widgets.
The set of valid options is certainly widget dependent (i.e. you
cannot have tkcget(radiobutton, xscrollIncrement=NULL) for instance),
and the full set of options is reall unspecified if you start thinking
of imported megawidgets and soforth.
Hmmm.... I think you need to store the list of options with the
widgets or their class somehow, so you'd soon be on the way to a true
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (firstname.lastname@example.org) FAX: (+45) 35327907
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: email@example.com