[GUI] Dynamic ... something

[Wolfgang Thaller]

> 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