Possible Grid Enhancements

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 ].

Weight on a slave

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.

Setting up slave defaults in a master

 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

Scrolled grid

 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 ]

DKF: For myself, I think this would be better off done as a megawidget.

Epsilon weight

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.

Linked row/column sizes

AMG: 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 visibly 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 the following layout. 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.

Peter Spjuth: Nice idea. It could be tricky to get a spec and semantics right for this one, but it should be doable. One possible spec is: Given that frame A and frame B are "column peers", frame A should take B's slaves into account when calculating its columns' widths, and vice versa. That should be enough to reach the goal and still be flexible and contradiction free. If you get a TIP through for this I should be able to provide an implementation.

CMcC - 2010-07-21 07:59:21

I think it would be a good idea to augment all widgets with a -grid {r c rs cs} option which would add the widget to a (pre-existing) grid with row, column, rowspan and columnspan arguments as specified by the option.

WubTk does it, so it must be good :)

Row/Column/cell insertion/deletion

CJB: 2010-07-21

I'd like to see Row/Column/cell insertion/deletion. This would give significantly greater versatility implementing dynamic widgets. Currently, I have to remove the slaves and re-grid them into their new positions. Possibly a relative cell placement as well.

e.g. grid .w -row 2 -column 2 -push up/down/left/right/none
e.g. grid .w -from .x -relrow -2 -relcolumn 3
e.g. grid insertrow .master -push right -index 2 -quantity 3

Where -push specifies which direction to push existing widgets. If a widget cannot move due to row/column span, then the whole section would have to move.

-push down

1 2 3     1 2 3 
4 5 6  -> 4 0 6
7 7 8     x 5 8
          7 7 x

ALH: 2010-10-05

I second CJB in insertion/deletion features. Although cell insertion/deletion would be nice, I would already be happy with full row/column insertion. I may have to write my own wrapper to insert rows, move -weight, -minsize, -sticky options. Hopefully I usually avoid row-span !

Temporary hiding lines/columns

ALH: 2010-10-07

With explicit size or visible option

grid lineconfigure $master $row -size 0        ; # default: -size {}
grid lineconfigure $master $row -visible false ; # default: -visible true

With introspection for removed widgets

Today neither "grid info" nor "grid slaves" doesn't return anything for removed widgets. When removing widgets from grid, one has to store the widget list in an array (using row, column or both as key). Info is already stored somewhere since "grid {*}$slaves" will restore their position, it is a just about adding access to:

grid removedslaves $master -row $row 
grid removedinfo $slave