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

[Vadim Zeitlin]

On Thu, 25 Oct 2007 02:01:44 +0200 Jeroen van der Wulp <J.v.d.Wulp at tue.nl> wrote:

JvdW> > JvdW> The failure to adopt modern C++ programming mechanisms
JvdW> > 
JvdW> >  This resembles marketing speak more than anything else. If you have
JvdW> > concrete proposals, please speak up. If you don't, I don't really see the
JvdW> > point of posting.
JvdW> 
JvdW> Let's start with namespaces again. Functions and classes that are not 
JvdW> part of the interface of the library can be put in a separate nested 
JvdW> namespace,

 Why should they be public at all? Currently such functions are declared
static inside the .cpp files (there we arguably should indeed use an
anonymous namespace for them but, frankly, nobody is going to notice this
anyhow). The use of namespaces, while nice in theory, is just not worth it
in practice and doesn't really bring anything except the dubious moral
satisfaction.


JvdW> One of the things I would consider a big improvement is stop using 
JvdW> macros for generating data types and associated operations. Templates 
JvdW> can solve the same problem, of course at the cost of compatibility with 
JvdW> older compilers.

 This is not the only cost. Another, often overlooked, one is much higher
compilation time (even with the latest and greatest compilers but
especially with the older ones).

 Anyhow, the above is not really being discussed: we keep the macros for
compatibility but we do advise people to use STL containers instead and we
did start providing some template-based classes ourselves in case the
standard library is not available (still a real possibility on some,
especially embedded, platforms), e.g. look at wxVector in the trunk.

JvdW> I would like to see the version of wxWidgets that is distributed with so 
JvdW> many Linux distributions, or OS X to have decent STL integration. For 
JvdW> examples, I would like to use std::string everywhere where I now use 
JvdW> wxString. But this may be impossible because of missing unicode 
JvdW> functionality, I can't tell.

 You can use std::string if you don't care about Unicode. It is convertible
to wxString. You can also use std::wstring although in practice I don't
know how many people do this.

JvdW> Then there is exception handling for error propagation instead of 
JvdW> passing through errors as return values of functions.

 Yes, it would be wonderful to use exceptions for error reporting, this
would simplify the API in a lot of places and make the code more robust.
Unfortunately this can hardly be done in a backwards compatible way and
there is also a huge problem with the exceptions not propagating through C
code (e.g.GTK+). So, once again, there is a huge difference between saying
that it would be good to do something and explaining how would it work in
details, let alone actually implementing it.

JvdW> Another popular request is to use signals/slots for event handling.

 This is not really popular, at least it's about the first time I hear
about it. wx events dispatch code certainly has problems but at a first
glance boost::signal has even more of them.

JvdW> I would already be satisfied with a more flexible callback mechanism 
JvdW> using functionality alike boost::function. It is so much more flexible 
JvdW> because it also makes it possible to trivially associate arbitrary data 
JvdW> with a specific handler, when required.

 Use wxEvtHandler::Connect().

JvdW> More of a general thought: I would like to see factory functionality for 
JvdW> widget creation (to avoid memory issues).

 This is another wonderful idea (and not at all because of memory issues
but because it would allow to change the factory during run-time and also
mix native and universal widgets freely) which nobody really knows how to
implement.

JvdW> Judging from what I have read here and on the wiki I am not alone.

 Not alone in what? Saying that wxWidgets is not perfect? Totally so, we
all know pretty well about its shortcomings. And I'll even claim that I
know them better than any of the outsiders, just because I know more about
wx details.

JvdW> It is a shame when people start their own projects with the same
JvdW> purpose (OMGUI) because they have a different view on how things
JvdW> should be done.

 We never knew about OMGUI (we learnt about it only accidentally) and I
have no idea about how are the views of its developers different from ours
as I don't know what their views are. Unfortunately they never really
shared them with us. It's regrettable but what can we do?

JvdW> From our project we observed that a significant amount of time is spent 
JvdW> on getting application behaviour consistent across platforms. These 
JvdW> problems are annoying and the time is lost to us, and we think it is the 
JvdW> same for many of those hundreds of other projects (for as far as they 
JvdW> target multiple platforms). We would rather spend those resources on 
JvdW> getting a proper solution in wxWidgets.

 Please do. Reporting such bugs would be an important first step.

JvdW> But if such consistency is not the goal of the wxWidgets project then
JvdW> there is no point in doing the effort.

 Any difference in behaviour between different platforms is by definition a
bug. As I said, nobody promises to fix all bugs but we certainly strive to
do it.

 Regards,
VZ


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