[Peter Lewerin]

A Snit object viewer, see [Snit's not Incr Tcl].

The code below is still very raw, and should be refactored and checked before serious use.  It doesn't seem to work in separate toplevels, probably because of the BWidget connection.

[http://home.swipnet.se/pelewin/images/snitscope.gif]
----

 package require Tk
 package require snit
 package require BWidget

 option add *Label*relief		raised
 option add *Label*anchor		w
 option add *Label*justify		left
 option add *Label*activeForeground	blue

 snit::widget snitscope {
     option -object
     onconfigure -object value {
         set options(-object) $value
         set object $value
         $self redraw
     }
     
     variable object
     variable frame

     method list {w label option} {
         grid [label $w.$option-label -state active -text $label] - -sticky ew
         foreach o [$object info $option] {
             if {[array exists $o]} {
                 if {$option eq "vars" && [regexp {::options$} $o]} {
                     grid [label $w.$option-$o -text $o] \
                         [label $w.$option-$o-value -text {(see Options)}] -sticky ew
                 } else {
                     pack [frame $w.f] -fill both -expand yes
                     grid [label $w.$option-$o -text $o] \
                         [$self listArray $w.f $o] -sticky ew
                 }
             } else {
                 if {$option eq "options"} {
                     set value [$object cget $o]
                 } else {
                     set value [set $o]
                 }
                 grid [label $w.$option-$o -text $o] \
                     [label $w.$option-$o-value -text $value] -sticky ew
             }
         }
     }

     method listArray {w a} {
         foreach {k v} [array get $a] {
             grid [label $w.k$k -text $k] [label $w.v$k -text $v] -sticky ew
         }
         return $w
     }

     method redraw {} {
         set w $frame
         eval destroy [winfo children $w]
         foreach label {name type} value [list $object [$object info type]] {
             grid [label $w.$label-label -state active -text [string totitle $label]] \
                  [label $w.$label-value -text $value] -sticky ew
         }
         $self list $w Options options
         $self list $w {Instance variables} vars
         $self list $w {Type variables} typevars
     }
     
     constructor args {
         set sw [ScrolledWindow .sw]
         set sf [ScrollableFrame $sw.sf]
         $sw setwidget $sf
         set frame [$sf getframe]
         pack $sw -fill both -expand yes
         $self configurelist $args
     }
 }

 proc demo {} {
     snitscope .sc
     pack .sc -fill both -expand yes

     .sc configure -object .sc
 }
----
''[escargo] 8 Dec 2003'' - The demo proc is defined, but never called in this code.

[Peter Lewerin]: yes, it's a "write-demo", not really a "run-demo".

Is defining a method named '''list''' a possible problem?
Conceptually, it might clash with the normal [Tcl] [list] command.

(PL): How?  It's never used except as a subcommand to the object command.  I use both in the internal code above.
Anyway, the code is not very well-written, I should re-write it some time.

[WHD]: No, there's no problem defining methods or typemethods with the same name as standard Tcl commands.  That's why the form "$self methodname" is used to call method "methodname" within another method.

''[escargo]'': I was not concerned with the ''software'' getting confused,
only ''programmers''.
A too-casual reading of the source might lead to misunderstanding.
(Or someone using '''grep''' or other searching tools might get a false hit looking
for one list or the other.)

[WHD]: I can only speak for myself, of course, but I often find it convenient to have methods with names like "list" and "set", and in reading my own code after a lengthy interval I've not found it confusing--simply because the method name is never the first token in a command.


----
[Category GUI] |
[Category Object Orientation] |
[Category Application]