Skip to content

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

4 messages · Thomas J Vogels, Peter Dalgaard

Original
Thomas J Vogels
# 
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"?)

Example:

   > tt <- tktoplevel ()
   > tkwinfo ("width", tt)
  [1] "200"

Could (Should?) be:

   > tt <- tktoplevel ()
   > tkwinfo ("width", tt)
  [1] 200

with 
   > tkwidth <- function (widget) as.numeric (tkcmd ("winfo", "width", widget))

Maybe a better example is the use of logical results:

  > if (tkwinfo ("exists", tt)) cat ("exists\n")
  Error in if (tkwinfo("exists", tt)) cat("exists\n") : 
          argument of if(*) is not interpretable as logical

Huh? Here you might have expected:

  > if (tkexists (tt)) cat ("exists\n")
  exists

with
  > tkexists <- function (widget) (tkcmd ("winfo", "exists", widget) == "1")

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

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?

Regards,
  -tom


[*] Nowadays, they have glorified strings into objects.  Anywho...
Peter Dalgaard
# 
Thomas Vogels <tov@ece.cmu.edu> 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.
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.
6 days later
Thomas J Vogels
# 
Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk> writes:
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.
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

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Thomas Vogels <tov@ece.cmu.edu> writes:

            

      
      
      
    

        
Sure, but it requires more detailed study of what the query-type
functions do, and what values they return.

            

      
      
      
    

        
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

            

      
      
      
    

        
[1]  "Push"

            

      
      
      
    

        
function()cat("Ouch\n")
<environment: 0x8b4641c>

            

      
      
      
    

        
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.

            

      
      
      
    

        
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.

            

      
      
      
    

        
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
object system.