[GUI] Class/Object Hierarchy

[Axel Simon]

I don't have any objections to what Wolfgang proposed.

Comments:

On Sun, May 04, 2003 at 12:33:54AM +0200, Wolfgang Thaller wrote:
> >>2) There will be a datatype Pane
[..]
> different terms. But in fact I don't care about how to call it.
Me neither. In gth2hs I use WidgetClass and I am happy as long as we don't 
use this name.

> >>5c) newFoo :: Container c => c -> [Prop Foo] -> IO
> >>Foo
> >
> >I do not like passing the parent to the constructor.
> >From a programmer's perspective, this limits options.
> >The main arguments for this is the implementation
> >details for certain toolkits would be hard.  I
> >earnestly think this is worth it though.
> 
> I earnestly think it isn't :-).
A big advantage of forcing the user to pass the parent: You cannot put a 
widget into two containers. If you need to create a branch without a 
parent you may as well use a lambda expression.

[..]
> It would make it _very_ hard to allow other native widgets to be 
> wrapped for use with CGA.
[..]
> But I'd really really like to have that feature...
Having backend specific widgets is a must. I am not afraid that users 
complain that passing the parent restricts them too much since some 
professional toolkits require that anyway.

> >>6) GridBox is a layout container that works like
> >>Gtk's Table, Java's
> >>GridBagLayout and Tk's grid.
> >>It should be implemented using Gtk's Table for Gtk,
> >>and implemented in
> >>Haskell for other platforms.
> >
> >My guess is that these different grid layouts have
> >different math behind them.  Since there will need to
> >be at least one Haskell implementation, we might as
> >well use it for all of them to enforce
> >standardization.
> 
> They are so similar that you can use all of them for some time without 
> noticing any differences; also, of the three, Gtk is the only one we 
> support directly, so why not use Gtk's table?
> But of course, if our own implementation turns out to be better if we 
> use slightly different maths, then I have no problem with that, either.

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.

> >I also strongly support use of HBox's and VBox's.  For
> >hand written programs, they are of great use in
> >organization of a gui.
> 
> As are GridBoxes. I have never used HBoxes and VBoxes myself, but they 
> look like they can be easily implemented on top of GridBoxes, so if 
> we're going to implement GridBoxes anyway, H/VBoxes are practically 
> free. I see no reason not to include them if you want them.
> HBoxes and VBoxes are not completely general, and I think grids are 
> better suited to UI builders, so I do insist on putting grids in sooner 
> or later.

The HBox and VBox you presented, David, seem to be overly simplified. For 
each widget in a box Gtk needs to know if the widget expands, stays its 
natural size or pads excess space. I guess other toolkits work 
differently. I think we should start with the easiest layout mechanism, 
which I suppose is the grid.

[..]
> >>	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?

Axel.