Hi, I'm already working on a GUI library for some time (three weeks). And come up with some designs and code. I'm sure to have it for review when ready and I would like to ask for comments here to get it going in the right direction. The code is in www.sourceforge.net/projects/cppgui The code is not completely compiling right now, but I'm writing it with support for win32/64, gtk and qt. The main design decision I have is that the GUI interface and the implementation specific code is completely decoupled. That way I can have a application that executes win32, gtk *and* qt at the same time. It is indeed what the first example does. In that, I call the implementations as drivers. And I can have the driver specified in the create window function. Just as this: wnd<> w = create<frame_window>( _driver = drivers::win32 ); For this to work, I had to create two hierarchies: window window_impl_base | | / \ / \ / \ / \ / \ / \ / \ / \ frame button frame_impl_base button_impl_base The first hierarchy is the one exposed to the user and the second must be derived from the drivers. The first can be subclassed by the user with this syntax: class my_frame : gui::subclass<my_frame, gui::frame> { my_frame() { wnd_lock<my_frame> w = wnd_pointer_cast_lock<my_frame>(wnd_from_this()); wnd_lock<gui::controls:button> btn = create<gui::controls::button> ( _parent = w, _size = std::make_pair(20, 20) ); btn_ = btn; } static void info(gui::create_info& i) { i.pos = std::make_pair(100, 100); } wnd<> btn_; }; And then the info function is called before my_frame instantiation automagically. This way my_frame can override the window creation properties before it is actually created by the driver. There's a injection of the window implementation in the window base class of the hierarchy too, so that calling GUI functions from inside the constructor would be safe too. Now, what I think is the most complicated part: wnd<> and wnd_lock<> classes. I decided to use functors as a way to execute handlers for GUI events. Therefore, window smart pointers could end up inside functors objects through boost::bind and others. The problem is: The window should be destroyable while waiting for user response. But if smart pointers inside functors were registered within the window, there would be a cyclic relationship that would prohibit it. And then I created these two classes. wnd<> being like weak_ptr in shared_ptr and wnd_lock<> would be the shared_ptr itself. I honestly do not like this solution and even less the wnd_lock<> name. It even seem to imply thread mutual exclusion, which it does *not*. Also, I found when using asio and win32gui that it is nice to have a class just for the handlers, which holds all its state. So I created a way to register event classes to windows, and to which you can return a functor that returns this event class object to be used in the handler binder. So you can do this: struct event_class { void btn_clicked(wnd_lock<> btn) { // do something } int x; // data required for handlers }; my_frame::my_frame() { wnd_lock<controls::button> btn = create<controls::button> ( _parent = wnd_from_this(), _text = "My button!" ); add_event_class<event_class>(); // this registers to call event_class::btn_clicked with // the event_class object under the window's lifetime management. btn->on_click(boost::bind(&event_class::btn_clicked , boost::bind(get_event_f<event_class>(), _1 )); } That way event classes can be completely defined inside a .cpp file, and any alteration to it wouldn't need the world to recompile, nor would be coupling between event handlers and the visual creation code. In theory, at least. But I find the syntax horrible for event registration and the event handler class ends up being referenced *a lot* inside the window's constructor. So, any comments would be *really* appreciated. And keep in mind that the library is in pre-alpha state (and that's why I'm posting this rfc here, so that I can find a better design to code). Which means that most parts aren't implemented yet. (Most controls, dialogs, resource files, etc). Thanks and best regards, -- Felipe Magno de Almeida