Wolfgang Thaller wrote:

*) We might need to add the parent widget as a required parameter to the constructor functions. Apple's "Carbon" API requires the toplevel window to be known at construction, the exact place in the window's widget hierarchy can be changed later. Widgets cannot be moved from one window to another. Win32 requires the parent widget to be specified at widget construction time, but it also provides a function called SetParent that's supposed to change a window's parent. Gtk doesn't seem to impose any restrictions, and neither does Apple's "Cocoa" API (formerly known as OpenStep). What about other potential backends?

Xt requires the widget's parent to be specified at creation time, and doesn't allow the parent to be changed thereafter.

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

OTOH, Xt does treat top-level windows (shells) as widgets, and operations on shells are performed using the same mechanisms as for other widgets (i.e. XtAddCallback, Xt{Get,Set}Values etc). Also, shells have a parent; for "main" windows, the parent is normally the primary application shell (created by XtAppInitialize), while dialogs normally have their parent set to their "owner" window. Also, both Motif and Athena treat menu bars, menus and menu items as widgets (actually, menu items are usually "gadgets"; these don't have their own window, but otherwise behave like widgets), while other platforms may treat these specially. -- Glynn Clements

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.