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