From: David Bergman (davidb_at_[hidden])
Date: 2004-03-04 12:15:01
David Abrahams wrote:
> button("click me") doesn't have to be a widget. Think
> expression templates. It can just build up a type to be used
> by window to add a button.
As usual, David is right ;-)
Look at some of the GUI implementations for Haskell (it is legite to mention
Haskell now after FC++ has entered the Boost scene ;-)) They use
expressions, which are converted to GUI elements through monadic
I love the notion of *only* dealing with (abstract) expressions when
constructing things, and then having it come alive at some point, such as
when the expression is attached to a main window. That way, one can more
easily serialize/deserialize whole GUI trees, and avoid carrying around
"ifdefs" in the GUI expressions. It is a bit similar to the Bridge Pattern
applied in the Java AWT library, where all GUI components have peers doing
the dirty work, but I would prefer an even more lose connection, through (1)
GUI Syntax on one hand and (2) GUI Interaction on the other.
Losing the wrapper luggage, we could focus on proper expressions for GUI
components and write (dynamic or precompilation) converters from XUL or any
other XMLish specification onto that expression language. Then, it is "just"
a matter of (monadically) blow some life into the expressions, via
gui::gui_toolkit g; // The implementation, corresponding to David
// Certain people do not like 'list' being reused ;-)
// The iterators are saved, but not traversed for now.
// 'occupationList' is just an expression, holding the "frozen"
gui::list occupationList(occupations.begin(), occupations.end());
g.add(occupationList); // This is where the list come alive, and the
iterators are traversed
One question is whether Model Objects should be attached to the GUI
expressions or the live GUI components? If attached to the former notions,
they will have to be frozen, and then populated by the GUI components. Yes,
there is a transaction problem here...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk