[Xotcl] Re: [Xotcl] Widgets

[Gustaf Neumann]

>>>>> "RH" == Rick Hedin <rhedin@aquifer.geology.uiuc.edu> writes:
RH> Hello all.

RH> I want to build an object on top of a canvas.  The object adds
RH> some internationalized features.  I'm not clear how to manage the
RH> XOTcl object in conjunction with the Tk object.  For now, I'm just
RH> managing the two as separate entities.

RH> Icanvas icanvas .f  ;# I pass the path for the tk object.
RH> pack .f.icanvas -fill both -expand true  ;# And manipulate the tk object
RH> with tk commands.

RH> Or maybe I should:
RH> pack [icanvas tkpath] -fill both -expand true

RH> Or give my object a truly wicked name:
RH> Icanvas .f.icanvas  ;# Will this work?

  yes, if the intention is that the Tk widget instance has the name
  ".f". but i would not recommend to determine from the XOTcl object name
  the name of the Tk widget.
 
RH> Or wrap every tk command in my xotcl object.

  Sometimes, this is a straight forward solution to keeps the
  XOTcl objects and the tk widget in separate trees. Architecturally,
  this is not a beauty.

RH> What is your thinking regarding widgets from XOTcl?

  For now, we have not definite answer.
  You might check the following solution, that is conceptionally
  quite simple. For each "XOTcl Widget" an tk object with a leading
  dot is created. It handles [self], xotcl methods, instance variables
  and should be easy extensible for most purposes.

 best regards
-gustaf
=====================================================================

#!/usr/local/bin/xowish

# make generation of tk widgets easy configurable
Class parameter tk

# Widget is a metaclass, that provides the generic create method to
# the Widget classes.  For each XOTcl object, a Tk widget with a
# leading dot is created.
Class Widget -superclass Class
Widget instproc create {name args} { eval [[self] set tk] .$name; next }

# The Class TkWidget handles the flags, that are useful to redefine
# for XOTcl.  We want to be able to work with self in callbacks, we
# want to sent instances variables of Objects, and so on. Everything
# unknown is delegated to Tk configure.
Widget TkWidget
TkWidget instproc s {} {string trimleft [self] :}
TkWidget instproc invoke cmd { eval $cmd }
TkWidget instproc command cmd { 
  .[[self] s] configure -[self proc] [list [self] invoke $cmd]
 }
TkWidget instproc textvariable v { 
  .[[self] s] configure -[self proc] [self]::$v
 }
TkWidget instproc unknown {m args} {
  puts stderr "UNKNOWN eval .[[self] s] $args"
  eval .[[self] s] configure -$m $args
}

# we want to support the following widget classes
Widget Button -superclass TkWidget -tk button
Widget Label -superclass TkWidget -tk label
Widget Entry -superclass TkWidget -tk entry

# well, now our application:
Button hello -text "hello world" -command {[self] text [self]}
Label l -text "Enter some text:"
Entry e -width 20 -textvariable input
Button quit -text "exit" -command {[self] print}
pack  .hello .l .e .quit

quit proc print {} {
  puts "entry var: '[e set input]'"
  exit
}