Hi Jesse Booher wrote:
dave@boost-consulting.com 03/04/04 08:59AM >>> button("click me") doesn't have to be a widget. Think expression templates. It can just build up a type to be used by window to add a button.
Well said. This exemplifies the reason why most gui toolkits are so horrible to use, they allow implementation technicalities to dictate interface. Having to decide where an object is going to live before any of its properties can be set is a clear violation of object oriented design principles but we live with these kind of problems all the time for supposed technical reasons.
Okay, you make a good point. On the other hand, I think that requiring child elements to have an explicit owner is good design; the problem is that the constructor syntax for widgets doesn't make it clear that they are in fact being constructed by the owning window. If the syntax were: window w("Test"); button b = w.spawn("button"); b.label("Click me"); w.contain(b); then the situation would be much clearer. At a broader level, I'd argue that there is a good reason to use this document/elements design because the type of the widgets have to match the type of window they're going to go into. Does that sound strange? Consider a linux implementation that allowed a run-time choice between a Qt and a GTK interface - or even both at the same time. It would clearly be an error to put a Qt widget into a GTK window. The document/elements model prevents this type of abuse. But as I said yesterday, I'm not religious :-). If my opinion is in the minority, I'll happily adapt the interface. Regards David Turner