Re: A BOOST GUI Library

From: williamkempf_at_[hidden]
Date: 2001-04-03 09:17:26

--- In boost_at_y..., Chuck Messenger <cmessenger_at_i...> wrote:
> From: David Allan Finch <sarum_at_v...>
> 
> >tom-list_at_h... wrote:
> >
> > > You should take a look at wxWindows (wxWindows.org).
> >
> >I have, the objectives of BOOST are != wxWindows.
> 
> I don't know if that's necessarily true.  Yes, wxWindows currently
> doesn't make use of templates/STL/etc.  However, I think the best
> possible outcome would be to evolve wxWindows in this direction.
> 
> I believe that the principals of wxWindows see this as inevitable,
> in principle (I'm a newbie to wxWindows, and to Boost for that
> matter -- this is based on what I've read on their site).
> 
> The advantage of evolving wxWindows toward STL is that wxWindows
> is a fairly mature system.

The wxWindows library is very similar to MFC.  This means object 
heirarchy problems, messaging systems that limit you to GUI messages, 
macro approaches to generating "message maps", etc.  It's a simple 
library to use, yes, but it's not nearly OO enough for most Boost 
user's tastes.  A signal/slot mechanism would go a long way to fixing 
this for wxWindows, but there are other things that need changed as 
well.

> Cross-platform GUI's are a very messy branch of programming.
> There are a host of platform-specific areas such a framework needs
> to address, such as file systems, peristence, networking, etc.
> So far, BOOST seems to have only touched on the edges of some
> of these -- e.g. threading and directories.  wxWindows goes
> all the way.

Sorry, most of the mechanisms you mention are NOT part of a GUI 
framework.  The fact that many GUI frameworks mistakenly include them 
does not change this fact.  The mechanisms provided by these 
frameworks are usually flawed because they're added as after thoughts 
to a library that's not concerned with anything but GUI programming.  
Boost is much better poised to address these non-GUI concerns because 
they're being built with out the concept of a GUI framework by people 
expert in the various domains.  This is another reason why wxWindows 
is not a good solution for Boost.  (And again, I say this with out 
meaning to criticise wxWindows, which is a fine portable GUI.)
 
> So there's a very natural fit.  It ought to be a seamless fit.
> But how to make it happen, as a practical matter?  From my
> perspective, it would sure by nice.  Then I'd have at my disposal
> a truly powerful "write-once-run-anywhere" system.

If that's all that you want, just stick with wxWindows.  Boost has 
other goals in addition to WORA, and I don't believe wxWindows fits 
most of the other goals.
 
> Actually, I almost have that now, as things stand.  There's nothing
> at all preventing me (that I'm aware of, yet) from using wxWindows
> with STL/Boost/etc (as I'm just starting to do).  It would just be
> that much nicer if wxWindows was modernized.
> 
> A relatively small optimization, really, in the scheme of things...
> 
> About Qt:  The problem with that, from my perspective, and as I
> understand it, is that it isn't an open system.  Open makes all
> the difference to me.

No one's suggesting using Qt for Boost.  Wouldn't work.  What's being 
suggested is that the Qt approach using signals/slots is much more 
flexible and a better design for a Boost GUI to start from.  A Boost 
GUI would more than likely be a fresh product, not a "third party" 
library ported under the Boost distribution, but such a library needs 
to start with a design likely borrowed from another library(s).  Qt 
has a better design in many ways than wxWindows.

Bill Kempf