[GUI] Class/Object Hierarchy

[Wolfgang Thaller]

>> 2) There will be a datatype Pane
>
> I don't think we need this datatype.  Since Windows
> are not going to be widgets, we simply need Widgets
> and Windows.

This is simply a difference in terminology.
I was avoiding the term "Widget" because many people are used to 
thinking "Windows are Widgets". Most toolkits (all that I can think of) 
that use the term "widget" follow this model, and most toolkits (again, 
all that I know) that don't follow the window=widget philosophy use 
different terms. But in fact I don't care about how to call it.

> As for menu items, these seem to be more of an
> attribute of a menubar than a widget itself.  This
> also simplifies things.

Probably an attribute of a menu or menu bar, perhaps an object of their 
own, but definitely not a widget. Also, a menu bar is not a widget 
because it's not necessarily inside a window.

>> 3) ... along with a class IsPane (or PaneClass or
>> ...)
>> 	class IsPane p where
>> 		toPane :: p -> Pane
>
> This is similar to the IsWidget thing which I agree
> too.

It's the same thing, by a different name.

>> 4) There will be a class Container
>> 	class Container c where
>> 		-- member functions to be determined
>> And we'll have
>> 4a) instance Container Window
>> 4b) instance Container GridBox
>
> From a programmers perspective, having a Container
> class is of little or no use.  This is especially true
> since each container might have a different addChild
> function. (see more comments below)

Yes, if we use specialized addChild functions, we can forget about the 
class.

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

>  There are
> two ways to implement this:
>
> 1) Try to work around it on the C side of things.
> Maybe one could derive a parent that doesn't show
> children.

That's not possible. The main limitation of Carbon and Motif is not 
that you have to specify the parent at widget creation; the problem is 
that you cannot change the parent afterwards (Xt) or that you cannot 
move a widget to a different window afterwards (Carbon).
If we put newly-created widgets in some container where they are 
invisible, they'll stay there forever :-( .

> 2) On the haskell side of things, all attributes and
> RO variables must be mirrored.  This would be easy for
> most attributes (since once the standard is complete,
> it would be easy to create a generator for most of the
> work).

Yes, but besides the obvious doubling of work, it would have one more 
disadvantage.
It would make it _very_ hard to allow other native widgets to be 
wrapped for use with CGA.
I would like to be able to create some widgets with platform-specific 
functionality, and then
manipulate it with CGA functions.
If those CGA functions insist on moving widgets to different windows, 
the CGA implementation will have to be able to read out _all possible 
attributes_ of _all possible widget types_ (even those not directly 
supported by the CGA) and recreate the native widget elsewhere. 
Definitely not possible, at least not for Carbon.
But I'd really really like to have that feature...

> I realize that smooth implementations is a strong goal
> for this project, but this is a really large chunk of
> logical and grammatical functionality we are
> sacrificing here.

Being able to just "cast" a native widget to a CGA widget is important 
functionality, too.

> I think my previous post which talks about eliminating
> Windows deserves some serious thought.  Perhaps, once
> implemented, it can be critiqued for its merits
> instead of discarded for to its originality.

You could of course provide an example in order to convince me and 
everybody else. But for now, I really fail to see the advantage. A 
Window is a real thing, that I want to be able to create and set 
attributes of. Why should it be automated away (at great implementation 
cost, because that really doesn't fit with any backend, and it doesn't 
fit at all with some backends)?
What would we gain by eliminating Windows from the API?

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

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

>> We have
>> 6a) instance IsPane GridBox
>> 6b) instance Container GridBox
>
> Again, I only see a need for
>
> instance IsWidget GridBox
>
>> 6c) Layout constraints can be set using attributes:
>> column :: IsPane p => Attr (GridBox, p) Int
>> (and more attributes as required for a grid layout
>> algorithm)
>>
>> 	set (box,button) [column =: 1, row =: 1]
>
> Compared to
>
> addToGrid theGrid 1 1 theButton
>
> the above code lacks in readability and intuitiveness
> IMHO.

But row and column are not the only attributes; I just used the default 
values for the others in the above example.
The attributes provided by Gtk's table are, IIRC, row, column, row 
span, column span; Boolean attributes X expand, Y expand, X fill, Y 
fill, X shrink and Y shrink (though I haven't yet figured out what the 
"shrink" attributes really do in Gtk...).
Those are more optional attributes than can be managed using 'Maybe' 
parameters to an addToGrid function, so I tried to use attributes.

Also, if we provide a "FixedPlacementBox" (in order to implement other 
layout algorithms on top of it), we would have attributes that we would 
want to be able to change after the fact, when recalculating the layout 
due to window resizing. For that, the above "set" command looks 
relatively practical and intuitive. There might be better solutions 
though, only I wasn't yet able to think of them.

Cheers,
	Wolfgang