A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework: [1] Support constructor-based window creation, e.g.: frame.add( new gui::button( "Boost!" )); The justification for this is that I find using an OnCreate + Create style for creating windows (MFC and WTL) or similar is too complex: the above method for creating a component is 1 line compared to many lines in other frameworks. For the record, I have a basic version of the above implemented in Windows where the add function changes the parent of the child component. This would make it easy to implement advanced GUI like docking controls. [2] Support for lightweight components: components that do not use native window handles. This will allow for advanced facilities like layout managers. The infrastructure should be such that using native and lightweight components is transparent. Component positioning should be allowed to be set explicitly (absolute position - using the units library?) or set using layout managers. There should be wrapping, clipping and stretching position schemes for the various layout managers. [3] The event manager should be platform independent, flexible and extensible. That is to say, if you are using Windows, you should be able to register a handler for a Windows-specific message. In general, the library should match system messages to an independent version wherever possible. It should also support message reflection where a message for a component is handled by a different window or object (e.g. responding to a close message on an application object). When an event is handled, the handler should inform the manager how to process the event: (1) the event has been handled (e.g. focus events); (2) the event was not handled - try the next handler; (3) the event was handled, but processing should continue (e.g. draw events) There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects? If so, this would increase the size of each component. Also, what if you want a "handle all events" handler. (2) if generic events are defined in an 'event' object, and a handler function has the form: event_handled_type eventfn( const event & e ); what if you want to support: event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke ); Regards, Reece