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.