tcl/tk button or toplevel pathname conventions

Question

Hello all. When one creates a new toplevel or button in TK, one needs to enter a pathname. I have seen a basic code which looks like:

toplevel .a
...
button .a.b ...

My question is: Are the dots treated differently than letters? Are they some sort of hierarchy delimiters, which create parent child relationship? I have looked at wiki TK and failed to find an answer to that. Many thanks, -Lior

Answer 1

Yes, they are! They separate for instance a frame with the content that are widgets:

set f [frame .hello]
button $f.b -text "Hello button"

pack $f.b

pack $f

As you can see in this example, the f is evaluated as variable, not f.b

You can also write pack ${f}.b but this is not needed as the dot is seen not to be part of the variable.

Answer 2

Yes - it's for the hierarchy. Have a look at TkDocs on the subject:

The frame, which was a child of the root, was named ".c". We could have put pretty much anything in place of the "c", naming it for example ".content". This name is purely for use by your program, so it's best to choose something meaningful. The controls that were children of the frame were given names like ".c.feet", ".c.meters", ".c.flbl", and so on. If there were any widgets at a deeper level of the hierarchy, we'd add another "." and then a unique identifier.

Answer 3

As other answers have said, dots are used to represent a hierarchy, just as / or \ is used to represent a filesystem hierarchy.

Placing widgets in a hierarchy is not, strictly speaking, necessary. One advantage in doing so is that geometry managers such as grid and pack default to managing children in their parents. For example 'pack .a.b.c' will pack the widget a.b.c within the widget .a.b. This makes it easy to do simple layouts.

The same effect in many cases can be achieved by telling grid and pack into which container a child should be placed. Foe example, 'pack .c -in .a.b' will put the widget .c in the container .a.b. This let's you keep your hierarchy shallow, and makes refactoring a little easier.

See http://www.beedub.com/book/2nd/TKINTRO.doc.html for a good introduction to tk fundamentals.