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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk