Peter Spjuth 2004-01-12 : This page is for collecting and discussing ideas about improving the grid geometry manager.
If you who feel that anything here is a really good idea you are encouraged to write a TIP for it.
Previous TIPs about grid are 37 [L1 ], 146 [L2 ] and 147 [L3 ].
This is a shortcut for a rather common grid case. To make a widget fill up its space becomes a one-liner.
frame .f text .f.t grid .f.t -sticky news -weight 1
If a slave has both "n" and "s" in its -sticky, its -weight is transferred to the row(s) it occupies.
If a slave has both "w" and "e" in its -sticky, its -weight is transferred to the column(s) it occupies.
If different slaves or a row/columnconfigure want to set contradicting weights (not counting 0), this is an error.
grid slavedefaults .f -padx 2 -pady 2 -sticky news
Affects any slaves added to that master in the future.
Maybe even:
grid slavedefaults all -padx 2 -pady 2 -sticky news
frame .f scrollbar .sbx -command "grid xview .f" scrollbar .sby -command "grid yview .f" grid masterconfigure .f -xscrollcommand ".sbx set" -yscrollcommand ".sby set"
This becomes a way to do a scrolled frame without the frame-in-canvas trick.
Experimental patch for this at [L4 ]
Allow an "epsilon" value for -weight that is larger than any zero and smaller than any other value. Currently weights that differ a lot like "1" and "100000" can be used to get this effect but that is a bit ugly.
If weights were floats could help too.
Another possibility would be to allow different weights for different situations, like initial layout, shrinking and growing.
Support having row/column sizes linked between separate frames/toplevels managed by grid.
This would make it easy to line up widgets that are grouped into multiple labelframes. (I currently solve this problem by not using labelframe. Instead I keep everything in a single gridded frame that is visible divided up by labels bracketed by separators.)
Combined with grid scrolling, this could facilitate spreadsheet-like locked header/footer rows/columns that only scroll in one axis. Here's a screenshot of such a user interface that would benefit from linked row/column sizes:
I'd like for it to have a layout like the following. The white regions don't scroll, the yellow regions scroll vertically, the cyan regions scroll horizontally, and the green regions scroll both ways.
I have had limited success getting it this way by using <Configure> bindings that set the minimum sizes to the requested sizes, but this is clumsy and doesn't play nicely with dynamically changing the ttk::style.