Re: [boost] GUI library - another one

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-03-07 11:28:06

Beman Dawes wrote:
> At 08:34 AM 3/4/2004, Peter Dimov wrote:
>
>  >... a window is not a stream.
>
> Agreed. A window is also not a pointer, even if all it actually
> contains is a smart pointer.

A 'window' with reference semantics is a pointer. But this is not the
important issue here, see below.

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.

He later added:

> Sure, though I would never call the function "add".  I'd be looking
> for declarative DSELs like:
>
>
>     window("Warning: now entering twilight zone")
>     [
>         text_field("my favorite color is:"),
>         button("OK") | button("cancel")
>     ]

And clarified that:

> I'm not interested in the free/not free debate, and I don't have an
> opinion on it.  I'm only interested in the syntax for building
> windows.

Douglas Paul Gregor agreed:

> I'm solidly behind the proposals to use a DSEL for describing GUI
> elements. It's the right level of abstraction for the task.

In my opinion, this approach, while enticing, is misguided. What makes it
dangerous is the consensus that is being built around it.

Please allow me to present the opposite point of view.

A GUI DSEL that masks the underlying architecture can do more harm than good
across all programmer skill levels, and, with all due respect to Beman, a
stream-based DSEL can be even more damaging, especially to novices (its
intended audience).

What is the most important task of a Hello World program?

It must teach the programmer the fundamental principles of the underlying
language or library.

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.

A stream-based DSEL can be even more deceiving, it not only masks this
important principle, but also establishes a false analogy with respect to
stream I/O, and can lead a novice programmer to believe that "C++-like"
equals "stream-based".

It is also important to show that the on_delete member of a window is a
plain ordinary boost::signal that can be manipulated independently of its
window owner, and that the only thing that wait_for_signal has in common
with GUI is that it automatically avoids one particular form of deadlock by
starting the message loop when invoked from the same thread that is supposed
to fire the signal.

The other important principle that GUI programmers will inevitably need to
learn, earlier or later, is that appearance and logic must be kept as
separate as possible. (Just ask anyone that has been programming active Web
sites.) In our domain this means that we must drop the E from the DSEL and
concentrate our efforts on supporting the use case where the GUI appearance
is described by a _separate data file_ that is not embedded in the C++ code.
We can afford to do that, because GUI building is not a performance-critical
task.

I have done GUI design in C++ code and believe me, it's a fundamentally
flawed approach. ;-) The compile-link cycle can drive you mad.

There are actually two Hello World programs, one that builds the GUI by hand
and hence needs to map closely to the underlying architecture in order to
'teach' it by example, and another, that simply reads a GUI description from
an external resource (XML is popular these days). We are trying to cram
these two introductory programs into one. This is not needed, and can be
harmful to both.