RE: [boost] GUI library - another one

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

On Behalf Of David Turner
...
 
> 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.

I agree with that.  Without an HAL type library anyone wanting to implement
a fancier interface would have to do it practically from scratch for every
platform they wanted to target.

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

That's good news.

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

Yes, and I think that we will be able to create a lot of useful software
with this level of abstraction.  No matter where you draw the line though
there will be some people who will feel that the interface doesn't give them
enough control.
 
> Have you had a look at the current interface?  I think it's very
> unsurprising.  From a newbie perspective, anyway.

Not yet but I will!  If your library has abstracted all the basic primitives
it will be easy to put a DSEL on top of it.

Brock