|
Boost : |
From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2006-04-13 09:01:54
Jeff Garland wrote:
> Andy Little wrote:
>
>> C++'s main problem is that it doesnt have enough standard libraries to compete
>> with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI.
>> ( I am going to try to do something about the GUI, though there must be much
>> greater GUI experts than me that could do a better job). A major reason given
>> by the committee AFAICS (in GUI case) was that the committee doesnt have enough
>> time to deal with it.
>
> Actually I believe the issue is that nobody has proposed a GUI library
> -- Bjarne has written many times about the desire to see a GUI library.
> But, its not really a surprise when you consider the huge amount of
> effort needed to do the design and development of such a proposal --
> just to give it away. From the academic side, there isn't much
> incentive to try and create a C++ GUI library.
>
> Honestly, I like to look at this the other way around. C++ is the only
> language that has multiple cross-platform GUI libraries -- it's bad for
> training and consistency, but you're not confined to what a single
> commercial entity provides.
I tend to agree. As we have discussed in another thread about GUI work,
there are really two orthogonal parts to this:
1) Develop a new GUI architecture, based on past experience.
2) Provide a set of C++ APIs that can map (at compile- or run-time) to
different backends.
Most people who think about developing a GUI API for C++ in the context
of boost seem to either think in terms of 1), or at least want to promote
very specific programming idioms, which restrict the choice of possible
GUI backends.
While I have done my own share of 1), I think for boost it would be
more appropriate to focus on 2). Still, it isn't clear that this
is possible at all, at least in general. As an exercise, take the major
GUI libraries that exist across all platforms and try to provide uniform
wrappers for them without 1) restricting yourself to the least common
denominator and 2) loosing performance due to late binding and many levels
of indirection.
Regards,
Stefan
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk