Re: [GUI] State, Attributes and Some basic widgets

On Wed, Apr 16, 2003 at 10:26:23AM +0100, Alastair Reid wrote:

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

...

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

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