[GUI] Dynamic sizing.

[Axel Simon]

On Sun, Apr 27, 2003 at 05:34:58PM +0200, Wolfgang Thaller wrote:
> Axel Simon wrote:
> >Actually the only way a grid layout is more
> >powerful seems to be the ability to put things into a matrix (e.g. a
> >tic-tac-toe playfield with 9 buttons with their borders all aligned).
> 
> No, that's not the only way, because widgets can span more than one row 
> and/or column.
> 
> I don't think you can achieve the following layout with H/VBoxes:
> 
> AAB
> DEB
> DCC
> 
> (where AA is just _one_ widget; There are 5 widgets here, A,B,C,D and 
> E).

Ok, granted. 

> >I don't really know about grid layouts, Gtk has one, but I think every
> >cell is of the same size, so it's not nearly as universial (and
> >complicated) as Motiv's.
> 
> No, Gtk's "table" does everything I want for a grid. The cells aren't 
> necessarily
> the same size (unless you set the grid to be "homogeneous").
[..]

> On MacOS, there is of course no other way (because the toolkit itself 
> provides only fixed layout), which is why fixed layout _has to be 
> there_ (as a base for implementing other things).

True, you have to be able to UI elements at specific pixel positions 
before you write your grid layout code. But if that interface is in CGA it 
means every backend has to implement it as well. I don't like that, but if 
you think it is easier that way, I will live with that.

> However, I don't see why there should be a problem with implementing 
> layout managers on top of fixed layout. The layout manager would just 
> have to query the (platform- and font-specific) minimum, preferred and 
> maximum sizes of the widgets. If the font settings are changed, the 
> layout manager has to be notified, and it has to redo the layout.
> 
> For Gtk, we might as well map the Grid layout manager to the native 
> table widget (as long as we don't want to add any features that Gtk's 
> table doesn't have). This would save us some coding effort (but it 
> wouldn't get us a more native look).

Perhaps I may request that the grid manager you will propose does not 
demand anything that is not in the intersection of grid managers of Gtk 
and Motiv. It's not only that I don't like reimplementing a fundamental 
part of Gtk (and loosing compatablity with GUI Builders), it's also that 
sending all these signals and going back and forth between Haskell and C 
will make Gtk even slower.

But otherwise I am happy with grid layout. HBoxes and VBoxes as an add on 
or backend-specific.

Axel.