--- Robert Ramey <ramey@rrsd.com> wrote: It seems that my post didn't make it through. I got the Boost post acknowledgement but the message did not appear on the list. I am trying to use another e-mail account. If the mailing list moderators would like to look into this problem, please e-mail me privately so I could give you my account information. Thanks. Anyway back to the GUI stuff.

I believe similar discussions were engaged some time ago and that these discussions resulted in:

http://sourceforge.net/projects/notus/

What to the participants in these other discussions have to add?

Well, I am quite happy with the direction notus is taking but there is a lot to be done. First I'd like to comment on the issue of simplicity. Simplicity is great but IMHO, it should NOT be of concern of the core GUI design. The higher layers could simplify the core interface any way they like. Like another poster pointed out if a feature is missing it could easily be a showstopper. It is like missing a letter in the alphabet. The primary concern of the core GUI design should be consistency, *scalability* and feature support. I think that the discussion of the syntax like using operators '<<' or '[]' and so on is important but it is a secondary issue. I think that what we are missing a consistent fundamental GUI design. All this syntactic sugar or XML support could be added at a latter stage. Most of the GUI frameworks with their endless polymorphic hierarchies and castings are not fun anymore. :) The fundamental GUI library doesn't have to support all possible features right from the start. It is more important to identify all fundamental features and architectures that will let you to scale the framework up with new features. Usually a GUI feature is not a standalone thing. It relies on presence of other features. A good GUI library should identify a set of *fundamental* features and architectures that will let the library grow vertically and orthogonally. Notus is based on what we call MDS (the DDV terminology will be deprecated). Model - application data Display - physical device such as window, button Strategy - user defined behaviors template <typename Model, typename Display, typename Strategies > struct view {...} A typical strategy looks like this struct my_strategy : handle_event<mouse> handle_event<paint> { template< typename View > void on_event( View& v, mouse& e); template< typename View > void on_event( View& v, paint& e); }; As you can see, the strategy event handlers take the event source (View) as a template parameter. So as soon as the View provides the interface that is required by this strategy, it doesn't care what View really is. So strategies can be used as interchangeable components. Strategies can be combined and reused. typedef view< my_data, displays::window, tuple<my_strategy> > my_window; //customize my_window typedef view < my_data, displays::window, tuple<my_customization, typename my_window::strategy> > my_custom_window; //my_custom_window reuses all strategies that are defined in my_window; I'd like to note that notus doesn't have any casting stuff and almost no polymorphism. The idea is to create a *generative* framework where components can be constructed from a set of interchangeable and custom parts. I'd like to touch the issue of ownership. The core Notus doesn't care about ownership at all, the physical devices such as windows, buttons, etc. are represented by Displays. One display can be connected to one or more other displays so that it will get events generated by the displays that it is connected to. So at this level, it is a *network* of display connections not an ownership hierarchy. I anticipate your question about what happens when the display's "physical" owner is deleted. Nothing really except that all the connections to the deleted display are lost. *Important* the displays don't keep direct references to other displays. I appreciate your comments. Eugene