[GUI] More notes on the example implementation

[Axel Simon]

On Sun, Apr 27, 2003 at 11:57:52PM +0200, Wolfgang Thaller wrote:
> *) We might need to add the parent widget as a required parameter to 
> the constructor functions.
[..]
> Gtk doesn't seem to impose any restrictions
No, indeed.

> *) As I already said, I think toWidget should be toWidget :: Widget w 
> => w -> Widget (not in the IO monad)
Yes, please. And furthermore I would really like to see the widget 
hierarchy implemented via type classes as done in gtk+hs (an earlier email 
of mine). This makes everything much more type safe. In gtk2hs these 
classes only implement this toWidget method and a private fromWidget. The 
latter is used to construct upcast functions which are checked at runtime.


> *) Should windows really be widgets? At least they aren't on Mac OS, 
> and making them look like widgets would be somehow artificial. Windows 
> can't be added to any layout container, for example.
This issue might go away when we define some standard toplevel windows 
like SDI (with a menu bar) or dialogs.

> *) I'm not entirely happy with the Has* classes. It looks like the 
> basic attributes and methods available for all widgets have to be 
> implemented over and over again for every widget class. Is there some 
> way around this?
In an earlier email I elaborated on the three possiblities:
a) put all the widgets attributes in a the Widgets type class
b) group related attributes in classes and make all widget that support 
these instances of these classes
c) put each attribute in its class and make all widgets that support it an 
instance of this class

The demo uses b) or c). I'd like to add and opt for
d) Make every attribute a normal function without any classes.

Disadvantage of the latter scheme: something like onActivate has to be 
called onActivateButton, onActivateMenuItem, etc. Gtk uses a similar 
approach: different widgets may define signals with the same name. In 
practice I have found 3 or 4 signals with the same name in the whole pile 
of widgets, so I don't expect this to be a problem.

> *) Fltk only supports a single callback, and so does the current CGA 
> example. To support multiple callbacks, some machinery has to be added 
> on the Haskell side.
I think I have to look at the code again... Why is this not enough for 
several callbacks?


Axel.