RE: [boost] Re: GUI library - another one

From: David Turner (dkturner_at_[hidden])
Date: 2004-03-04 13:32:34

Hi

> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] 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