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

[Bryan Petty]

On 9/14/07, myLC at gmx.net <myLC at gmx.net> wrote:
> First of all, thank you for your post. So far, all I've ever
> received from <wx-discuss> was a little Spam, instead of the
> vivacious discussion about wx V3.0 I had hoped for...

Most of that 3.0 discussion has mostly been kept on the wiki, where
it's a little more organized, and doesn't disappear with time. You are
right though, there just hasn't been a lot of discussion in general
about it. But it usually turns out that the people that want to see
3.0 go a certain direction are the same people that aren't doing any
of the work involved, so it's usually pretty pointless anyway. You'll
find this is the case with most of the details about 3.0 on the wiki
too.

> 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 problem of wx, as stated, comes with its roots. Hence,
> also no exceptions, namespaces and even no signal/slot
> mechanism (callbacks aren't that fancy, signals that work
> over threads/processes are by far more practical).

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.

> For example Windows itself is unable to provide a decent
> Unicode support. A 16-bit wchar_t simply doesn't do the job.
> You cannot fit all the languages and their symbols in there.
> As a result you cannot really use Unicode (such as UTF8)
> with wxWidgets, because it won't be PROPERLY supported on at
> least the Windows platform.

I don't think this is true. But Vadim may know best what you mean by this.

> C++ came with an incomplete STL. The biggest bummer: no GUI
> support. Also the STL itself has many deficiencies, like the
> absence of Unicode (UTF8 would be nice, wouldn't it?).
> Think about only a portion of that work going into
> completing C++ and fixing up the STL - putting it at eye
> level and above Java or C# (reads: "C crooked")?
> Unfortunately this is not going to happen by itself.
> The BOOST guys run a different (one-man?) show. Rather
> "conservative" - in a negative sense. I believe that even
> the idea of including GUI functionality seems repelling to
> their chieftains...

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.

Like us (but the other way around), Boost likes to leave the GUI
functionality job to someone else while they focus on stuff that can
be added to the C++ standard to work the same on all platforms.

> Wx 2.8/9 could continue to mature and support all exotic
> (and extinguished) platforms, while wxWidgets 3 could be
> something new - incorporating new C++ features (including
> the proposed language extensions - yes, BOOST where it makes
> sense). It wouldn't build with all compilers (eventually
> they evolve too), yes. So what? You'd still have wxWidgets
> 2.8/9 for that purpose...

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.

Regards,
Bryan Petty

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