aricb Too often I find that when I write Tk code to do anything non-trivial, I end up with a sprawling disaster that is a pain to modify or even understand six months later. As I'm sure other programmers have encountered this problem, I searched for some guidelines on the Wiki and on the web. I'll share what I found below. However, I came to the conclusion that much more could (and should) be said on this topic.
Here's what I've found so far (please add to this list):
Tom Tromey's style guide [L1 ] has an excellent section on Tk. By contrast, Ray Johnson's Tcl style guide [L2 ], which has become the de facto standard for Tcl, doesn't address Tk specifically.
A handful of wiki pages address this topic:
Here's what little I currently do to make my code more readable. Please share any reactions to these:
grid [text .mytoplevel.text] -row 0 -column 0
However, when I have to specify lots of options for the widget and/or the geometry manager, I end up with long lines which IMHO look bad even if I break them up with backslashes.
PWQ 12 Aug 2003 I use a table driven approach to gui creation. As an example
set widgetlist { {button $par.b -command xx} {entry $par.e -width 6}} foreach w $widgetlist { pack [eval $w] -anc nw }
(Peter Lewerin did minor edit to make it executable.)
The command as listed in the list (which can be spread out over multiple lines) become much easier to read.
I have a system that extends this concept but is to complex to outline here, here is an example screen as an example (Stored in a file/database etc is the gui definition ):
Options { *LogoEntry*Entry*font {Times 24} *LogoPanel*Canvas*width 600 *LogoPanel*Canvas*height 400 *LogoMenu*Button*ipadx 0 *LogoMenu*Button*padX 2 *LogoMenu*Button*relief solid } Form Logo { Script { namespace eval Logo {set __create 1.0} } V3S#LogoPanel { H#LogoMenu { V3s { H3r { PackOptions {-anc w -padx 1} H1s { PackOptions {-anc w -padx 1} T { } T {Test:} B {{Clear} {::Logo::test:clear} } B {{Check} {::Logo::test:check} } B {{Load} {::Logo::test:load} } B {{Save} {::Logo::test:save} } } Sb/Lv {{{-orient v -command {!Logo yview} -width 10 }}} {-fill
y}
Lb/Logo:Logo::data(_cmds) {-font {{{Times 18 bold}}} -width 0 {{ -yscrollc {!Lv set}}} } {-fill y -expand 0} V+b { E/Vars:Logo::data(_vars) {0} {-fill x} H+b { T { } T {Programme: } B {{Save} {turtleSave [!Prog get 0 end] [!Vars get]} } B {{Load} {turtleLoad !Prog}} ........
Notes:
H means arrange horizontally
V means vertically.
The # defines the class.
The second item in each list are short cuts for the most common widget option.
Ie B {{Save} -justify c} equals button -text Save -justify c.
The third list item are the manager options (ie pack).
/xx associates a variable with the widget.
:xx defines a reference to the widget that can be used in other widget definitions
Names above are abbreviations (is B is button, Sb scrollbar, Lb listbox etc.
Please contribute any principles that help you write Tk code in a more readable, manageable, and/or reusable way.