From: Stefan Seefeld (sseefeld_at_[hidden])
Date: 2004-09-24 10:19:57
> From: Reece Dunn [mailto:msclrhd_at_[hidden]]
> Sent: September 24, 2004 11:05
> There is also the issue of dynamically creating the GUI. If
> you create a
> docking/floating toolbar for example, which object stores the
> The docked frame or the floating frame?
> Also, what if you have a large number of GUI components?
> Storing them in
> the frame class would just increase the size of the object to
> the point
> where it is unusable.
> Also, doing:
> frame.add( gui::button( "Boost!" ));
> frame.add( gui::textbox( "Hello", 25, true ));
> would incur copy penalties. What if you want to share the same object
> across multiple objects (e.g. the docking/floating frame) instead of
> making a separate copy of it.
Indeed. This question is much more than a simple matter of
convenience. Some toolkits use a 'scene graph' - like approach, where
'outer' widgets wrap ('decorate') inner ones. Following this path further,
widgets could be shared by multiple parents, i.e. they could be rendered
at multiple positions on the screen (or multiple screens) at the same time.
I'v been working on the fresco project (http://www.fresco.org) and there
we push it even further: widgets are owned by the 'display server' which
applications talk to remotely (fresco is, much as X, network transparent).
So the object the application holds is just a proxy that will forward
all requests to the display server.