Russel wrote:

But this wouldn't catch at compile time me writing

label l = w.spawn("button");

True. You'll get a bad_cast exception. That's why you're encouraged to use the constructor form rather than using window.spawn directly. I might even decide to enforce that constraint by careful use of protected:. Regards David Turner

Angus Leeming wrote:

David Turner wrote:

...

window w("Test"); button b = w.spawn("button"); b.label("Click me"); w.contain(b);

Excuse me butting in, but this is redundant information: // b belongs to w button b = w.spawn("button"); // b belongs to w w.contain(b);

No, they are _not_ redundant. Writing "w.contain(b)" doesn't mean b now belongs to w. It says nothing about ownership. What it says is that w _contains_ b. On the other hand, w.spawn("button") says something about the genealogy of the button. It says it's the spawn of the window, and therefore belongs _somewhere_ in the window's hierarchy tree. Not necessarily as the direct child of the window. I should point out that that windows can only contain one widget. However, that widget might be a grid widget. This is an auto-sizing framework.

It seems to me that you're trying to fit two concepts into one box, the widget and its properties. All this jumping through hoops occurs because you're trying to manipulate a "widget that must belong to a window" when in actual fact you're interested only in its properties:

Yes I am trying to fit two concepts into one box, but those aren't the two concepts in question. The sticking point is that the window is both a container of a widget, *and* the factory for all widgets that will ultimately be contained within the window's widget hierarchy. Again, I appeal to the W3C DOM: body = document.createElement("body"); document.appendChild(body); div = document.createElement("div"); body.appendChild(div); Regards David Turner

Dave Abrahams wrote:

"David Turner" <dkturner@telkomsa.net> writes:

...

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.

You're still missing the point. The fact that the owning window constructs the child is an implementation detail that has nothing to do with the window structure/layout the user is trying to represent. The syntax for describing a window should be declarative, not imperative.

I'm well aware of the fact that owner windows are an implementation detail. I also know full well that if I wanted to, I could cope with a change of ownership. The point *I'm* making is that there are design and utility considerations as well as implementation considerations. By design, the window is the factory for all other widgets. A button in one window isn't necessarily the same thing as a button in another window; just as a bold font in one document isn't necessarily the same as a bold font in another. One cannot say in general that elements can be exchanged between documents. Similarly, one cannot say in general that widgets can be exchanged between windows. If you think this is a weak argument, then I'll be happy to change the interface. But please think very carefully about all the implications of having free widgets first. I believe this slight interface oddity is a small price to pay. Regards David Turner

Hi

From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Bergman

David Abrahams wrote:

...

...

You're still missing the point. The fact that the owning window constructs the child is an implementation detail that has nothing to do with the window structure/layout the user is trying to represent. The syntax for describing a window should be declarative, not imperative.

David Turner responded:

...

I'm well aware of the fact that owner windows are an implementation detail. I also know full well that if I wanted to, I could cope with a change of ownership.

I think you are missing the point a tiny bit. David (lot of those here...) Abrahams tried to accentuate the syntactical/expressionist properties of the GUI tree. I too think you gain a lot by keeping them as ASTs as long as possible, which are subsequently traversed by the particular GUI implementation (in your case, the "window" instance.)

Gah. you're right. I *am* missing the point. I was replying from Jesse Booher's thread. Looking at your other post, I see you're tending towards the idea of using the widget tree as a context rather than as an entity. This may or may not work. The main problem I have with it is that the metaphor doesn't adequately capture the user's expectations. In particular, the monadic or instantaneous nature of the transformation from expression to reality is a problem. User interfaces are interactive by nature. While the "gui expressions" approach is great for visualization of data, it doesn't really address the needs of, say, an "enter your name" dialog. But perhaps I'm mistaken? I can see that there is some argument to be made for the idea of a user interface as a sort of question-and-answer session, so that we might want to do things like: std::string name; (window("Enter your name") + textentry()) >> name; However, there are two reasons not to take this route: (a) it can be relatively easily implemented post-hoc, and (b) it tackles a slightly different problem domain. * I seem to be alone in my support for the widgets-are-owned-by-windows concept. That being the case, it makes sense to look at removing the requirement that widgets be spawned from windows. However, I would still like to have a WidgetFactory of sorts. In particular, I'm thinking about eventually supporting multiple factories for a run-time decision about which back-end to use. For example, it would be extremely nice to have a piece of software support command-line switches like --text-mode, --gtk, and --qt. Any suggestions as to how this should be done? Regards David Turner