RE: [boost] GUI library - another one

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2004-03-07 14:10:50

Peter Dimov wrote:

> Please allow me to present the opposite point of view.
> 
> A GUI DSEL that masks the underlying architecture can do more harm than
> good

How can a cross-platform GUI library not mask the underlying architecture?

...

> 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".

I agree with this.  GUIs are not streams.

...

> 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.)

The reason that this is true in traditional GUI environments is that there
is a tremendous amount of housekeeping and overhead in even very simple
interfaces.  It makes sense to isolate this code because there is so much of
it that has very little to do with the logic of your program.

The truth is, however, that the appearance of an application has a great
deal to do with its logic.  Changes in a program's logic will almost always
change its appearance.  If you can automate the largely redundant
bookkeeping behind a GUI all you really have left is expressing the
relationship between your program's logic and its appearance.  This is done
with a DSEL.

> 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.

But then you still have to define the relationship between your program and
this external data file.  If your logic changes you have to change your C++
code and the external file.  Many mistakes that could have been caught by
the compiler will be delayed until runtime.  For comparison what if in
Spirit you had to put your EBNF in an external file instead of embedded in
C++?

> 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.

My goal with the GUI library I've made is that you only need to know C++ to
use it - I don't want our programmers to have to waste their time mastering
the ins and outs of MFC - I've already suffered for them :).  Again, I don't
see how any platform independent library can "map closely" to the underlying
architecture.

Brock