[GUI] Class/Object Hierarchy

[Wolfgang Thaller]

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