[GUI] Dynamic sizing.

[Wolfgang Thaller]

Axel Simon wrote:

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

For now, I'd say, let's put the FixedPlacementBox in the "sample 
implementation".
It will also be in the Mac OS version.
We could still decide to rename it to "FixedPlacementBoxEXT" later 
(although I'd
still like to have it, because I have actually once encountered a 
situation
where I needed fixed placement).

Whats important for myself is
a) That a FixedPlacementBox fits in the interface (if the "addChild" 
function has
a hard-coded type that disallows fixed placement, that would be bad)
b) That a FixedPlacementBox is present in at least one non-Mac OS 
implementation,
so that I have something to compare my implementation with in the early 
phases.

I think we can agree on that, and we can revisit the question of 
whether to
include it in the public interface later.
For Gtk, it should be trivial to implement a FixedPlacementBox using 
GtkLayout.

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

OK, I think Gtk's "Table" provides enough features (roughly the same 
feature
set as Java's GridBagLayout and Tcl's grid).
 From Glynn's posts, I gathered that XmRowColumn doesn't have enough 
features,
and that XmForm works completely differently. So unfortunately, a grid 
layout
manager will have to be "emulated" for the Motif backend.

> [...] it's also that
> sending all these signals and going back and forth between Haskell and 
> C
> will make Gtk even slower.

A cost, that we, unfortunately, can't avoid for the Mac OS and Win32 
platforms...


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

OK. While they are simple to implement on top of Grid, they provide no
real benefit. Let's ignore them for now, and include them later only if
someone speaks out for them (but there's no need for discussion of 
H/VBoxes now).