Updated 2014-06-07 17:04:34 by dkf

Sometimes I'm responsible for maintenance of an application that includes such elements as
    pack [button .b1 -text Lion -width 10] [button .b2 -text Hippopotamus -width 10]

[show picture here] Notice that there's a problem with this fragment; 'Hippopotamus' is truncated. That's not a good thing. Most immediately, it's because .b2 has been assigned a width that's too small. Generally in Tk it's OK to allow things to have default sizes; there are a couple of legitimate reasons to assign manifest sizes, though, including that of a label whose -text varies occasionally, while its -width needs to be constant, so the display layout doesn't jerk around, yet has enough room for all the possible values [... and ...--but people also mistakenly set sizes when ...].

One effect that required manifest -widths before recent Tk releases was that of equal-width buttons. PWQ, KPV, BBH, GPS, FW, and Donald Arsenau worked with CL to achieve this demonstration of the modern idiom for achieving it:
    frame .f0
    frame .f1

    button .f0.b01 -text Simple
    button .f0.b02 -text Complicated
    button .f0.b03 -text Done

    button .f1.b01 -text Simple -width 10
    button .f1.b02 -text Complicated -width 10
    button .f1.b03 -text Done -width 10

    pack .f0 .f1
    grid columnconfigure .f0 {0 1 2} -weight 1 -uniform f0
    grid .f0.b01 .f0.b02 .f0.b03 -sticky ew
    grid .f1.b01 .f1.b02 .f1.b03

Outdated comments follow:

PWQ '20 Dec 03' Can you give a real example of when the size of a widget (such as a label) need to be specified. Without such an example, my comment is that this is completely unnecessary. Either you want the label to be shown in full or not. If not then the label text should be truncated before displaying. (ie Hippo...) I get annoyed when I see TCL apps that people have assummed the width based on the font they have and it truncates on my display. This is the sort of bullsh*t that you get with VB applications.

KPV Both these situations are usually best handled by the geometry manager--grid is especially good at this. In the first case, either keep the widgets in the same column with property --sticky ew or use the columnconfigure -uniform property. This occasionally won't work when the widgers are in different gridding masters. In the second case, I usually design the GUI to have plenty of space reserved for such labels then have the geometry fill up the space completely (again with -sticky ew or -expand 1 -fill x).

GPS: It sounds as though you want to set the -weight of the (column/row)s which you want to grow. Look into the rowconfigure and columconfigure subcommands to grid.

BBH: If you have the cells of the grid like you want, you just need to add -sticky ew to make the widgets fill the cells. 15 Jan 2004 - you don't need any calculations use the -uniform option to columnconfigure
    grid columnconfigure .f0 {0 1 2} -uniform 1

If those widths are constant values, they need to be correct ones. Too-small labels make bad impressions on users. Here's a way I ask an application to tell me about itself: I source in
    proc walker {w procedure} {
      $procedure $w
      foreach child [winfo children $w] {
        walker $child $procedure

    proc check_width w {
      switch [winfo class $w] {
        Button -
        Label {
          set original_width [$w cget -width]
          set x_extent [winfo reqwidth $w]
          $w configure -width 0
          set needed_x_extent [winfo reqwidth $w]
          set result [expr $needed_x_extent > $x_extent]
          $w configure -width $original_width
          return $result
        default {
          return 0

then execute
    proc c w {
      if [check_width $w] {
        puts "Widget '$w' isn't wide enough."

    walker . c

The truth is, that's not exactly what I do, but it's close enough. For sufficiently weathered applications, and especially ones that have moved around between platforms, I usually pick up a few widgets that I'd rather find this way than by having a customer complain.