$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Jurko Gospodnetic' (jurko.gospodnetic_at_[hidden])
Date: 2007-10-21 13:45:00
   Hi.
> Not to be too hard on wxWidgets, but wxWidgets isn't even near what I
> expect from a C++ GUI library.
> 
> [...snip...]
> 
>> And an existing library such as wxWidgets already has a giant lead in the
>> right direction.
> 
> But I disagree with this.
>> 
   Hmmm, what parts did you find lacking? (I do not wish to sound brisk 
here, I am actually very much interested in the answer.)
   We have found it to be a tool allowing us to implement portable GUIs 
using C++. Sometimes class design or other implementation detail 
encountered in it smells a bit but whenever we approached any concrete 
problem we found the developers to be most responsive and I can not say 
we found any extreme design flaws nor anything set in concrete an 
unchangeable. On the other hand, the library allowed us to solve all the 
GUI related tasks we set before it.
   We also use a great wxFormBuilder form designer together with it, 
allowing fast visual and portable form design during development. Also 
open source and also an extremely active and responsive project. 
Preparing the needed similar toolset for a new library seems like a 
really daunting task...
> To get anything near of what I want, it would be needed to rewrite
> wxWidget from scratch, so I don't see much difference in approach.
   Again, I would have to better understand what you expect from a GUI 
library in order to understand this. As I said above... so far we have 
not found any big enough problems with wxWidgets.
> Why doesn't wxWidgets use boost? It doesn't have to be included in
> boost to use it. boost.asio used boost even before it was added
> (boost.bind) IIRC.
   I really do not know why it does not use boost. Most likely the two 
library evolved separately and so there is fear that depending on boost 
would reduce their platform portability. I personally believe they 
should but that is a topic for their own mailing list.
   I also believe that most work with any hypothetical wxWidgets/boost 
library integration would be in the initial step to upgrade wxWidgets to 
use boost functionality wherever possible instead of its own (possibly 
improving respective boost library implementations in the process).
>> (thus removing the need for double maintenance efforts). Also, users
>> would find it easier to learn/access both of the libraries.
> 
> I can't see how. IMO, there would probably be more discussion than
> development, because of the two different views at C++ development
> from wxWidgets developers and boost developers.
   I can not say I ever saw any drastically different views regarding 
C++ development in these two groups. My guess would be that both groups 
automatically consider the other 'different' enough and that no one has 
enough reason to push for better integration between the libraries.
   For that matter... I do not either, personally... We already use and 
are acquainted with both libraries and both are being maintained 
separately from us with high enough quality. The only potential issue 
with the two libraries not being cohesive enough is that there is 
duplicated code in both (different implementations for the same tasks) 
which can and does confuse new developers coming into both libraries. So 
far we have dealt with the issue by using wxWidgets only for tasks not 
supported by boost, which pretty much comes to just its GUI part.
   And if I had to cast my vote for 'the most needed C++ library' it 
would be a good logging library and not the GUI one... :-) That is the 
one area where we have not been able to find a 'good enough' solution 
for our needs.
   Best regards,
     Jurko Gospodnetic'