Re: [boost] Re: Re: A BOOST GUI Library

From: Andrew Green (ag_at_[hidden])
Date: 2001-04-04 02:26:38

I've got some opinions on the notion of a boost-blessed GUI toolkit (don't
we all?) The uncertainty of the Apple's direction regarding a standard
toolkit in the early 90s, along with my desire to be able to accumulate code
that could be reused not only in applications but in other plugin style
environments led me to develop what's now called ZooLib. I've been working
on and with ZooLib since 1993, during which time it's evolved tremendously
and been used by many other developers. Along the way I've put in a lot of
time experimenting with wrapping and being compatible with other toolkits.

The upshot of my experience is that a full-blown GUI toolkit is hard to wrap
usefully unless it was written from the beginning with the intent that such
wrapping would occur. Furthermore, although providing a single interface
over multiple toolkits is possible I've found that providing one that's
actually worth having, that provides genuinely useful abstractions for real
world work, is either impossible or at best has a complexity as high as any
of the kits it wraps. In which case its advantages are really limited, its
maintenance cost will be as high as that of any of the kits. So if the goal
is to minimize work at the kit level one might as well use one of the kits
directly. This is one of those things that looks to be feasible at first
glance, but gets tricky pretty quickly.

The work to abstract ZooLib from the details of different hosting
environments on MacOS was a strong foundation for going just a little
further and abstracting some of the specifics of the OS itself. Along the
way I've come to see GUI APIs as having an hourglass 'shape' -- there's a
fat high-level interface, and a fat low-level interface, but in between it's
as if there's a platonic ideal API that's quite narrow. Abstracting _that_
API can be a big win. That's why sitting on top of multiple GUI kits is hard
-- they each have a fat API and very different ways of slicing the universe.

Where I think there's scope for immediately beneficial work is abstracting
stuff at the waist of the hourglass. std::strings are a good example. For
all that one can criticize the details of their API, just having a single
entity that can hold a string and move it around safely is an enormous win.
Regions similarly -- they're used everywhere in GUI code, most often just
being stored or passed through. A simple typedef for HRGN, RgnHandle,
BRegion*, XRegion etc can be enough to make big swathes of GUI code more
portable. Regions are also a good example of something that has an agreed
ideal interface, and although not all of that interface is implemented by
every platform it is possible to plug the gaps that each platform has.

Although it's very interesting to think about providing a complete stl-savvy
boostified APIs over existing GUI toolkits, a reachable goal and one that
would help us explore the territory together is defining APIs and providing
implementations of the things we _know_ are used everywhere. As a start I'd
suggest regions, rectangles and points.

A+