[boost] Re: boost Windowing Toolkit

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-12-13 00:23:06

From: Dave Abrahams <abrahams_at_[hidden]>
> Greg calmly elucidated:
> > I don't doubt this is great stuff -- but is it enough better than Qt to spend
> > time on, or would we be better off leveraging that already popular and
> > almost free work?
> >
> > For those who may not know, Qt is the C++ windowing toolkit underlying the
> > Linux KDE desktop.  See http://www.troll.no/qt/ and http://www.kde.org/.
> 
> Well, as far as boost is concerned, I think Qt is really inappropriate.

I didn't mean we should bring Qt into Boost, I was just giving an example
of one a few already freely available C++ windowing codes, and wondering
whether the world needs another.

> Instead of using namespaces they're using a Q prefix on all names. Instead
> of using the standard library they're using their own collection classes.

The lack of namespace use seems like just an artifact of needing to work
with a lot of old compilers.  It shouldn't be that difficult to move stuff
into a namespace in the future, once compiler support is better.

> Finally, it requires some sort of meta-object "compiler" outside of C++,
> which I think generates C++ source code. We really do have all the tools we
> need right here at home, I think.

I also dislike their use of a preprocessor.  A useful contribution might
be to figure out how to implement their design without it.  Extra credit
for binary compatibility with their current implementation.

> An important feature of what I'm proposing is that it would be easily ported
> to environments without an underlying windowing system (e.g. GGI, which
> we've already got something working on). I don't think Qt fits this
> description. Also, I don't think they really got the architecture right.

Probably not, but Qt is clearly "good enough", whatever its quirks.  The
KDE desktop and application suite are impressive evidence of that.

The other big contender is GTK, which is the C toolkit used by Gnome and
Mozilla.  Also "good enough", with impressinve results.  There are two or
three C++ wrappers for GTK, but I haven't had time to look at them.

So another question -- could your interface be easily ported to
environments that already have an underlying window system?

> But ultimately, your question is a good one. Can we do something that is
> enough better than existing work to be worth spending time on? I have not
> been very impressed with the GUI toolkits I've seen out there. In contrast,
> I've been very impressed with the work done "at" boost.org. I think we can
> do much better. It remains to be seen whether the interest is there.

I'm sure we can do much better, I'm just being skeptical of the interest.

The Boost stuff we have so far has been relatively small, self-contained
tools.  If even a modest number of people find some of the tools useful
then that is great.  If other designers find good examples and inspiration
that is great too.  All of them are small enough that if Boost went away
you could maintain the code yourself, so there is no great risk to using
them.  And all of them consist of clean, standard conforming code, with
little if any dependence on non-standard interfaces, so in most cases no
maintenance would be needed.

Windowing systems are another story.  They tend to be large, and depend of
necessity on non-standard underlying services.  The choice of windowing
system can make a big difference to your application architecture, so to
choose the wrong one can leave you stranded, with slim hope of maintaining
the code yourself.  Maintenance will be needed, as underlying services
change, user preferences evolve, and new systems come on the market.  Have
you loaded up a really old Macintosh or Windows program recently?  Did it
even run?  If it did, just how primitive did it look?

I say all this as someone who once made my living at writing cross-platform
GUI toolkits, both of which died slow and miserable deaths.  So I am very
interested in seeing it done right, but battle-scarred enough not to be in
a big hurry to be on the front lines.

So what would I like to see?

At the API level, a set of abstractions that would make it remarkably easy
and fun to do GUI programming.

At the system level, some way to make it remarkable easy to make and
maintain ports to many underlying drawing and windowing systems.