|
Boost : |
From: Arvid Norberg (c99ang_at_[hidden])
Date: 2004-03-04 06:15:05
Me and Daniel Walling have been toying some with a gui library approach
where the user would build the gui trees using a DSEL. Something like
this:
void clicked_ok(button::clicked_event e)
{ /* .. */ }
void clicked_cancel(button::clicked_event e)
{ /* .. */ }
int main()
{
window w("my gui");
gadget my_gui =
+ vgroup()
+ "Buttons below me!"
+ hgroup()
+ button("OK") [ button::clicked = &clicked_ok ]
+ space()
+ button("Cancel") [ button::clicked = &clicked_cancel ]
- hgroup()
+ button("Maybe") [ button::clicked = &clicked_maybe ]
+ space()
+ button("Foobar") [ button::clicked = &clicked_foobar ]
;
w.set_gadget(my_gui);
w.show();
/* ... */
}
which would produce a gui like this:
+---------------------------+
| Buttons below me! |
| |
| +----------+ +----------+ |
| | OK | | Cancel | |
| +----------+ +----------+ |
| +----------+ +----------+ |
| | Maybe | | Foobar | |
| +----------+ +----------+ |
+---------------------------+
of course the functions would be boost::function and possible to
boost::bind to member functions. The expressions within the
[]-operators should of course be a list where it's possible to
assign callbacks for more than one event.
One important requirement I see with a gui lib is to be able to
easily create dynamic guis. Where sub-trees can be exchanged, removed
or added on the fly.
-- Arvid Norberg David Turner wrote: > Hello > > It seems that the idea of adding a medium-complexity GUI library to boost > is popular, but that there are widely varying opinions on how it should be > done. > > I've written a first draft of a library that fulfils most of my > expectations. It's available at http://www.turn.co.za/david/gui. It > supports two platforms (Win32 and GTK2), and four user interface elements > or widgets (window, label, button, text-entry). The design is such that > it is extremely easy to support new platforms or widgets. > > These are my expectations of how a good C++ GUI library should behave: > > 1. It should be a consistent yet thin wrapper around the platform's > native functionality. > 2. It should degrade gracefully in the absence of certain features on the > platform. > 3. It should be extensible through the factory pattern. > 4. It should couple loosely with user code - this means no inheriting > from an abstract Window class. > 5. It should do what the user (programmer) expects, whenever possible > (i.e. no leaky metaphors). > 6. Widgets that contain things should behave like containers, whenever > this is practical. > 7. It should not use device-specific units like pixels, wherever this is > practical. > > and finally > > 8. It should be extremely easy to use. > > The library at the link above fulfils most of these requirements. But > it's not perfect. There are some interesting design choices. > > In many respects the most difficult design work is still to be done (list > boxes, menus, drawing areas). However, the code that exists has the great > advantage of working. > > I'd like to know what the boost community thinks before proceeding. > > Regards > David Turner >
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk