[wx-discuss] Re: More wxTNG Discussion (was: aspects of a safe future)

[Jeroen van der Wulp]

>> As for today wxWidgets still ignores most of C++'s
>> accomplishments, making programming not that much fun.
> 
> Like what? Templates are used when built with --enable-stl. Namespaces
> would be used if any of us found that they actually payed off, but
> none of us can see any advantage to them that would be a big enough
> reason to justify the change. What else are we missing here?

The STL integration is far less than optimal. I have never been able to 
do a complete build with --enable-stl. There were always lots compiler 
errors (it is advertised as YMMV in wx/setup.h). I want to program using 
the standard library and the concepts that it uses. The container types 
used by wxWidgets have different interfaces. Furthermore they are 
generated by macros, why not templates? On recent versions of gcc the 
code generated from such macros used in header gives a lot of warnings 
(because of void* casts). The use of templates or better use of the 
standard library containers would avoid these warnings.

Why is the use of namespaces seen as enough of an advantage to adopt it 
for wxWidgets? It clarifies and brings some order in things that are 
otherwise just put in the same place. The failure to adopt modern C++ 
programming mechanisms will distance the project from many people that 
see the use of such mechanisms as an advantage (or even a necessity). I 
will not even consider joining the wxWidgets effort as long as it uses 
the C-but-with-classes-in-C++ programming approach using lots of macros, 
avoiding exceptions and having no decent STL integration.

> Being that wxWidgets it's a free library (without anything coming in
> from commercial use other than help with development even), there's
> not nearly as much manpower as compared with a toolkit like Qt (which
> like you said, is maybe 2nd best). Without this manpower, most of us
> like this trade-off where rather than wxWidgets building a signal/slot
> library, we like to share this responsibility with the Boost project.
> Boost has a fairly nice signal library for example. wxWidgets + Boost
> is a really powerful combination.

What exactly is the mission of the wxWidgets project? I was hoping it is 
something like: providing a portable easy to use graphical user 
interface framework. It is not very easy to use in combination with the 
STL and uses different approaches to otherwise familiar concepts (from 
STL). The only thing I currently seem to get is that my program compiles 
on another wx port. There are lots of things that are not working the 
same way accross ports.

Don't get me wrong I am sure that saying it is a lot easier than 
actually creating and maintaining consistent behaviour across platforms. 
  I have a lot of respect for anyone that wrap platform dependent 
frameworks to build solutions such as wxWidgets. What I would like to 
see is more commitment toward getting the same result on the different 
ports.

We are developing the mCRL2 toolset (http://www.mcrl2.org) and have been 
using wxWidgets for over two years now. Every now and then we are 
surprised to find big differences in behaviour of the user interface of 
our tools between the three platforms we support (Windows, Linux, Mac OS 
X). The ListCtrl component is a very famous source of such differences. 
Especially dragging/dropping but also sorting. For example wxMac 
automatically sorts by what is in the first column. On other platforms 
this does not happen. Another example is the wxGLCanvas that does double 
  buffering with wxGTK and wxMac but does not with wxMSW. All platforms 
have the capabilities so why these differences?

It may be possible for us to pay people to do small projects to improve 
wxWidgets. At least when the objective is to obtain consistent behaviour 
between platforms. For me this should start with a good fundament 
(wxTNG) and a testament of commitment to at least provide a recognisable 
subset of wxWidgets that has consistent behaviour between platforms.

> 
> Boost isn't a "one-man" show, and you should really read up. Boost is
> where C++ standards are born, and it often dictates the direction in
> which it goes. Many of the developers on the Boost project are the
> same ones publishing the C++ standards.
> 
> GUI functionality is a completely different arena. Can we honestly
> come up with a "standard" cross-platform GUI design and behavior? One
> that themes well across all platforms? wxWidgets doesn't think so,
> it's why this project was started up to wrap the native design and
> behavior where possible.
> 
What problem <does> wxWidgets solve? I want to build an application that 
works more or less the same everywhere (at least functionally the same). 
Should I use Java/Swing or Java/SWT instead? If this is not the problem 
that wxWidgets tries to solve I would expect to see details of platform 
specific behaviour in the documentation. Also what is missing is 
information on what functionality is implemented, works or does not work 
in which port. Preferably I do not want to still have to do platform 
dependent programming when using wxWidgets.

It must be possible to have a compatible subset of functionality with 
behaviour that is the same accross all ports. A subset for which you can 
guarantee compatibility accross platforms. I would like to know what 
behaviours constitute a bug in wxWidgets and what behaviours should be 
considered features or side effects.

> Like us (but the other way around), Boost likes to leave the GUI
> Why add this requirement when we can leave that choice up to the
> application developer? Less unnecessary dependencies is the key here.
> There's nothing that needs to be wrapped with Boost, and there's
> nothing in wxWidgets that really needs to use Boost itself. From my
> personal preference here, it might be nice if wxDateTime was removed
> in favor of boost::date_time, but there's not anything wrong with
> wxDateTime, it works fine, and runs fine. It's a little slow for my
> purposes, but other applications that don't heavily depend on mass
> date calculations work perfectly fine with it, and this is enough in
> most cases to avoid needing a dependency on Boost.

But there is no choice. If I want to use boost::date_time instead of 
wxDateTime in combination with a date picker control then I should 
convert back and forth manually. So I end up using both...

Generally I like the boost equivalent versions better than those found 
in wxWidgets. I have the feeling that the Boost libraries get more 
exposure and better testing. And I like the fact that they are often 
stand-alone libraries instead of part of a mamoth framework. Besides I 
believe in a lean-and-mean wxWidgets without date/time, filesystem 
manipulation, theading, etc. functionality builtin. The maintenance of 
non-core functionality can then be left to others...

I do not know about licensing issues that could arise when distributing 
a selective set of Boost libraries. By taking them up in the wxWidgets 
distribution, the dependencies on Boost libraries can be controlled. 
Much the same as the bundled image format support libraries.

Also the other way around. Why does it not happen that a solution in 
wxWidgets ends up in Boost? What the current version of Boost is lacking 
is a library to start and manipulate processes. Much the same problem is 
solved with wxProcess.

Regards,

Jeroen van der Wulp


---------------------------------------------------------------------
To unsubscribe, e-mail: wx-discuss-unsubscribe at lists.wxwidgets.org
For additional commands, e-mail: wx-discuss-help at lists.wxwidgets.org