[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 [http://tip.tcl.tk/37.html], 146 [http://tip.tcl.tk/146.html] and 147 [http://tip.tcl.tk/147.html]. ---- **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 [http://sourceforge.net/tracker/?func=detail&atid=312997&aid=1870368&group_id=12997] [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 [frame]s/[toplevel]s managed by [grid]. This would make it easy to line up widgets that are grouped into multiple [labelframe]s. (I currently solve this problem by not using [labelframe]. Instead I keep everything in a single [grid]ded frame that is visibly divided up by [label]s bracketed by [separator]s.) 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: [http://andy.junkdrome.org/tmp/beatbox.png] 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. [http://andy.junkdrome.org/tmp/layout.png] I have had limited success getting it this way by using [bind]ings 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 :) ---- !!!!!! %| [Category Suggestions] |% !!!!!!