RE: [boost] GUI library - another one

From: David Turner (dkturner_at_[hidden])
Date: 2004-03-07 15:38:34

Hi

On Sun, 2004-03-07 at 21:10, Brock Peabody wrote:
> Peter Dimov wrote:
> > 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.

This is definitely beside the point.  It may make sense to lay out the
GUI with a DSEL, and it may make sense to use a data file.  I'm not
interested in tackling that problem (directly), and I don't think it's
the business of the hardware abstraction layer to present one or another
interface.  The HALs job is to be as close as possible to the hardware -
but no closer.  This GUI library is, by and large, a hardware
abstraction layer.  In many ways, it's comparable to boost::thread or
boost::filesystem: it represents the underlying primitives directly, but
in such a way as to be (a) much easier to use in terms of housekeeping,
and (b) safer in terms of reducing programmer errors.  Fancy frameworks
can be built on top of it.

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

The devil is in the details, as they say.  In fact, almost all platforms
that have a GUI support more or less the same primitives: windows,
buttons, text-entry boxes, menus, selection boxes, list boxes.  The
abstract representations of these can be mapped very closely indeed to
the underlying implementation without any significant impact on
portability.

I think there is a threshold where the underlying implementation changes
from being dead-simple to being a nasty, bloated hack that's difficult
to follow and dangerous to maintain.  The trick is to sneak in just
under that threshold, while still keeping the interfaces abstract enough
to be unsurprising.

Have you had a look at the current interface?  I think it's very
unsurprising.  From a newbie perspective, anyway.

Regards
David Turner