Hello Peter Dimov wrote an excellent post to which I can only say "Hoor, hoor!" (which means the same as "hear, hear", only it's a little less understated than the English ;-)). I think the primitives that appear on-screen should map as directly as possible to the C++ constructs that represent them. Most importantly, their lifetimes should be the same. This means, for example, that the window should not disappear automatically just because the user clicked on the little "X" in the title bar. That action is properly represented as a signal - a notification of the user's desire to have the window closed. What actually happens after the signal is generated is up to the programmer. I've tried to make explicit the fact that the lifetime of the program as a whole is governed by a (possibly quite complicated) boolean condition. Thus instead of, say, MFC's DoModal() method, we have the more generic wait_for_signal construction, or wait_for_bool_condition: gui::util::boolean_condition time_to_close; void do_exit() { time_to_close = true; } window w("Example"); w.contain(button("Exit", &do_exit)); w.delete_signal().connect(&do_exit); wait_for_bool_condition(time_to_close); The gui C++ objects are not abstract representatives of the _properties_ of the widgets, they represent the widgets themselves. A property representation/DSEL is perfectly possible, it's just outside the scope of what I'm trying to achieve. I also agree with Peter that making the appearance part of the code is (apart from trivial cases) a fundamentally flawed approach. Better is to implement some sort of serialization schema a la Glade XML. Again, this is outside of the scope of the gui library proper. There is one issue that I think would benefit from some serious debate, because there is a reasonable case to be made for both sides:
In our case, given a GUI architecture that does not support unowned/free widgets and clearly distinguishes between ownership and containment, a Hello World program must clearly communicate these principles to the user.
On the whole, I think the fact that there should be ownership semantics in a GUI library is totally counterintuitive. It took me a long time to "know" in a visceral sense the difference between an Owner and a Parent (in Windows parlance). It still doesn't make sense in many ways. I agree with David Abrahams that this sort of detail should be hidden away from the user. Metaphors shouldn't leak; Donald Norman's advice applies equally to programmers designing interfaces for other programmers :-). On the other hand, I'm not sure that we should be encouraging programmers to copy-paste elements between windows. Two windows aren't necessarily implemented the same way. Why should their elements be compatible? The idea of the window as the entry-point to the implementation, and as the factory for all other elements, is quite appealing. And of course there are the implementation efficiencies ;-). http://www.w3.org/DOM/faq.html#ownerdoc At the end of the day, the strongest argument for encouraging the owner-window model is the practical one. Thus if I were forced to concede that practical issues should not make a difference to the design, I must conclude that the owner-window model is not the right one. I'd like to hear some more comments about this, from both sides. In the mean time, I'm implementing a free-widget version of the library, which I'll release later tonight as concept-3. Depending on which way the discussion goes, the first testing release can branch off from either concept-2 or concept-3. Regards David Turner