So far, we've been arranging widgets in displays by
interface to the packer geometry manager in Tkinter. This section
grid, the most commonly
used alternative to the packer.
As we learned earlier, Tkinter geometry managers work by
arranging child widgets within a parent container widget (parents are
Frames or top-level
windows). When we ask a widget to pack or grid itself, we're really
asking its parent to place it among its siblings. With
pack, we provide constraints and let the
geometry manager lay out widgets appropriately. With
grid, we arrange widgets in rows and columns
in their parent, as though the parent container widget was a
Gridding is an entirely distinct geometry management system in
Tkinter. In fact, at this writing,
grid are mutually exclusive for widgets that
have the same parent—within a given parent container, we can either
pack widgets or grid them, but we cannot do both. That makes sense, if
you realize that geometry managers do their jobs as parents, and a
widget can be arranged by only one geometry manager.
At least within one container, though, that means you must pick
pack and stick with it. So why grid, then?
grid is handy for
laying out form-like displays; arranging input fields in row/column
fashion can be at least as easy as laying out the display with nested
frames. As we'll see, though,
grid doesn't offer substantial code or complexity savings compared ...