[boost] Re: boost Windowing Toolkit

From: Beman Dawes (beman_at_[hidden])
Date: 1999-12-12 10:47:41

At 01:27 PM 12/11/99 -0500, Dave Abrahams wrote:

>> Are you talking about a full-fledged GUI toolkit, or a lower-level
>> windowing toolkit from which someone else could build a
full-fledged
>> GUI toolkit?
>
>A "full-fledged GUI toolkit" is not a well-defined term. You
probably mean
>something which incorporates all of the following:
>
>1. An application framework
>2. Standard control components
>3. Some file handling
>4. Persistence for GUI objects
>5. Some kind of view layout editor
>6. Font pickers
>7. Color pickers
>8. Interapplication communication
>9. Scripting
>10. Object collaboration
>...etc...

Well, I would have included 1, 2, 6, and 7.  The others I see as
separate.  But I get your meaning in any case.

>What I am proposing does not include any of the above, but provides
a
>paradigm on top of which all of the above can be implemented fairly
easily.
>
>> Sure, it would be wonderful to have a boost.org portable C++
>> full-fledged GUI toolkit.  But lots of people have tried; see
>> www.geocities.com/SiliconValley/Vista/7184/guitool.html for a
>> listing.  None have caught on.  Why?  My guess is that it is much
>> harder that it looks.
>
>Yes, I've done extensive work in this area before; it can be hard.
I'm
>familiar with the list you quote.
>
>Some of the reasons nothing has caught on, IMO, are:
>1. Dominance of certain platform APIs (nothing to do about that).
Usually
>people start to look at cross-platform GUI libraries when they
discover they
>have to port what they've already got working.
>2. Existing attempts are hard to understand and port
>3. Existing attempts are closely tied to a single API's paradigm
>4. Poor use of C++; interfaces are difficult to use (safely).
>5. Licensing!!

Agreed. My list of reasons is virtually identical to yours.

>> And it looks hard enough at that.  It would be
>> a very large project, and would roll on and on in time.
>
>I am proposing to provide an interface (and some implementation) for
the
>fundamentals only. I don't believe that such a toolkit must be built
as one
>huge, monolithic entity. Each of the items enumerated at the top of
this
>message can be seen as a small(ish) project. In fact, I think this
is a
>problem with existing toolkits: too much integration!
>
>> So while I am personally very interested in such a project, I also
>> think it needs to be approached very, very carefully.
>
>I agree. The greatest risk is that we will work on this and nobody
will
>care.

How should we proceed?  Seems like some real-time discussion be
helpful. Ideas?  

--Beman