[GUI] Class/Object Hierarchy

[Wolfgang Thaller]

I'll try to summarize the discussion about how to arrange the 
class/object hierarchy, admittedly with some bias towards my own 
opinions. I'd just like to confirm if we really have agreed on what I 
think we've agreed [like many people, I have a tendency to think that 
everyone agrees with my opinions unless I hear a clear "no" :-) ].

So what have we already agreed on?

1) There will be a datatype Window

2) There will be a datatype Pane

3) ... along with a class IsPane (or PaneClass or ...)
	class IsPane p where
		toPane :: p -> Pane

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

Open Issue/Disadvantage of this solution:
What type would a "getContainer" function have? Can we have such a 
function at all?
What are the alternatives to a class Container?

5) For a particular widget type Foo, we will have
5a) data Foo
5b) instance IsPane Foo
5c) newFoo :: Container c => c -> [Prop Foo] -> IO Foo

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.

We have
6a) instance IsPane GridBox
6b) instance Container 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)

Example:
	box <- newGridBox container [columns =: 2, rows =: 2]
	button <- newButton box [...]
	set (box,button) [column =: 1, row =: 1]

7) Below the "Pane" type and class, we'll try to keep the hierarchy 
flat (perhaps even absolutely flat), so that we don't have any problems 
with mismatches between the interface and backend implementations.

===

Undecided issues:

8) Will there be a datatype for a general Widget (in addition to the 
datatype for a general Pane (Point 2)) ?

data Widget
along with
class IsWidget w where
	toWidget :: w -> Widget

Pros:
*] Common features of Windows and Panes can be implemented very 
conveniently on platforms where both Windows and Panes are represented 
by a "Widget" object.
*] Having both getWindowSize and getPaneSize seems unnatural; having 
getSize in a type class sounds nice, but might require that all Pane 
types explicitly instantiate that class, always with the same 
implementation, for example:
	
	instance HasSize Button where
		getSize b = getSize (toPane b)

Cons:
*] Not all platforms have that common representations; implementations 
on other platforms would have to use a discriminated union type and 
lots of case expressions, for example:

	getSize w = case toWidget w of
		WindowWidget win -> getWindowSize win
		PaneWidget pane -> getPaneSize pane

*] The only common feature of Windows and Panes that I can think of is 
size and position on screen.
*] The Parent/Child relationship is not such a common feature, as there 
are no cross-platform parent/child relationships between toplevel 
windows. Also, one widget being contained in another widget is not the 
same thing as one window being a child of another window (the latter 
has nothing to do with containment, except with MDI).
*] There's no reason to need a general list of widgets, where Panes and 
Windows can be freely mixed.

9) Do we prefer to use a) too many type classes, i.e. a
HasFoo class even when there's only one widget that supports foo,
or do we rather want to risk having b) too few type classes, i.e.
making foo a plain function when we may later add another widget that 
supports the exact same foo?
I think the performance costs of type classes are absolutely 
negligible, but what about namespace polution and readability of error 
messages?


So that's all for now, feel free to add your own points. - I'd also 
like to know what other people think I've agreed to, when in fact I 
haven't :-).

Cheers,

Wolfgang