Axel Simon wrote:
Right now I definitely want to use Gtk's table. Xt and Gtk are the only toolkits that support resizable dialogs. While the dialog is resized the grid layout code is executed all the time and implementing that in Haskell will be quite slow (just because of crossing the C/Haskell boundary). This is just not necessary on Win32/Carbon since it only needs to be done once when the widget is created.
Let's start out with the GtkTable feature set. When (if) we get the urge to add features that GtkTable doesn't have, we should already have both implementations to compare performance. One more remark: You seem to assume that we will never need dynamic resizing on Mac OS and Windows... Both platforms _do_ have resizable dialogs (the File Open & Save dialogs, for example), although most dialogs are fixed size (conversely, I've also seen non-resizable Gtk dialogs). Also, we'd want to use some layout mechanism for document windows, too, and they definitely are resizable. So if the C->Haskell->C rountrip is really too slow, then we're in trouble. Fortunately, I'm convinced that it's fast enough: I've used HOpenGL, and I've seen GLUT windows resize absolutely fluently (where each frame was rendered by Haskell code).
[..]
set (box,button) [column =: 1, row =: 1] [..] the above code lacks in readability and intuitiveness IMHO.
I don't really like that either. Could we provide layout information of W when we create W?
The difficult thing about it is that the type of the layout information depends on the container... We could use something like this newButton :: Container c => [Prop Button] -> c -> [Prop (c,Button)] -> IO() so that we can write button <- newButton [title =: "Do Something"] box [column =: 1, row =: 1, columnspan =: 2] ... and we still can use the unintuitive set notation for changing it: set (box, button) [row =: 2] If we disallowed changing of layout information after widget creation, it would perhaps be possible to simplify the type of newButton (but how?). I would, however, strongly argue for keeping that feature, mainly because I'd like to do the following: I'd implement a FixedPlacementBox (at least for MacOS), which is a normal container that uses pixel coordinates and sizes as layout constraints. Then, I'd use some onResized callback to implement dynamic re-layouting, so I obviously need to change layout constraints afterwards. Cheers, Wolfgang