Neither do I. Which is why I'm so keen to see an API which separates the initialisation from the core application logic.
Yes, that's definitely a good idea. We'd have... a) programmatic creation & layout of widgets you execute some monadic IO actions, and in the end you've got a set of values of types like Widget, Button, whatever... b) platform-specific loading UIL/nib/etc. ... for people who want to design their UI once for each platform (i.e. more work), but get perfect results in terms of L&F. Let's start out with platform-specific extensions, and keep thinking about how to reconcile the differences. In an ideal world, we could use the same code and just different (i.e. platform-specific) interface definitions. Then you'd somehow extract references to the elements that you find interesting, and again, you end up with values of types like Widgets, Button, etc. c) People have been tossing around the idea of having our own interface definition file format. I think there is nothing that prevents us from implementing a library that loads some self-made cross-platform interface definition, based on a), just like libGlade is built on top of GTK. I don't think we need that for CGA 1.0, though. After doing one of a, b or c, you'd attach some callbacks to the widgets and go...
To me, the most important part to get right initially is the stuff which interfaces with the application logic, because that tends to be scattered throughout the code. Primarily state management; not just the generic set/get interface, but the semantics of common widget types (e.g. how do you specify a scrollbar position?).
Yes, somebody should already be writing down the minimum set of widgets and their attributes that we need for the first version.
For 3), I'm thinking of a high-level approach. Of course, there'd be the usual grid-based mechanisms (cf Java's GridBagLayout), but I'm also thinking of specialized layouts for special situations - like a "button bar" in a dialog box, where you just tell the layout manager which button is the OK button and which is the Cancel button and so on.
That's one case you probably don't need to handle. OK/Cancel dialogs should be available as complete components; if they are available, they should be used.
I was not referring to OK/Cancel message boxes, I was thinking about more complex dialogs with lots of different widgets, and a group of buttons that affect the entire dialog. Those buttons might be OK & Cancel, they might also be "Apply" and "Revert". There might also be some additional buttons, like "Revert to Factory Defaults" or "Save Settings as...". So I'm talking about something that needs to be a bit more flexible than all the readymade components that I've already seen. Of course, I don't really care if it's really a "layout mechanism" or something else that does the same job... Cheers, Wolfgang