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