[GUI] State, Attributes and Some basic widgets

[Axel Simon]

On Wed, Apr 16, 2003 at 10:26:23AM +0100, Alastair Reid wrote:
> 
> Glynn Clements <glynn.clements@virgin.net> writes:
> > The class hierarchy is only really relevant if you're writing new
> > widgets [...]  The only sense in which the class hierarchy is
> > relevant at the application level is that a subclass will have all
> > of the attributes of its parent class.
If you extract all the widgets from a container then you can actually 
return a list of widgets in Haskell. You couldn't do without a type 
hierarchy.

> > In any case, it probably isn't practical to model the class
> > hierarchy in the CGA, as different toolkits have different
> > hierarchies (e.g.  Motif's push-button class is a subclass of label,
> > but Qt's isn't).
...and Gtk's Button contain Labels. Of course we have to rearrange things 
a bit, but that's what a standard layer is for. I agree with Alastair here 
that creating a widget hierarchy with type classes is useful.

> Remember that we're not interested in the internal details of widgets
> or even in the interfaces between widgets - as you say, this is only
> relevant if we're writing new widgets (which we're not).
BTW.: I think drawing custom widgets is one aspect where people could 
really benefit from a common set of operations. But of course, that's for 
later.

I see three strands of modelling widget hierarchies in Haskell:

1.) Don't. Each widget has an individual type, unconnected to the other 
widgets. (Glynn's ponit of view, if I am not mistaken)

2.) Model only the hierarchy in classes. (This follows the example code 
I've sent earlier.)

2a.) Use one additional class for each attribute.

2b.) Lump together related attributes into a class.

2c.) Use different names for the same functionality if the functionality 
appears in different branches in the hierarchy tree.

3.) Model the hierarchy and the all operations/attributes in classes.


I would like to see 2., in particular 2c. 2b will always be ad-hoc, thus 
probably not right the first time round and hard to change in hindsight.
As said before, 2a is messy, especially as types get very long and there 
is no way in Haskell to control the export of type classes. 3 seems dodgy 
to me since dictionaries become huge and will contain nearly always the 
same functionality.

Any comments?
Axel.