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

[Jeroen van der Wulp]

Vadim Zeitlin wrote:
> On Wed, 24 Oct 2007 16:23:38 +0200 Jeroen van der Wulp <J.v.d.Wulp at tue.nl> wrote:
> 
> JvdW> The STL integration is far less than optimal. I have never been able to 
> JvdW> do a complete build with --enable-stl.
> 
>  You really need to submit bug reports if you want to make statements like
> this and be taken seriously. For the record, right now wxUSE_STL build
> works for me with both VC7.1 and g++.

You are right. I will try first thing tomorrow.

> 
> JvdW> Why is the use of namespaces seen as enough of an advantage to adopt it 
> JvdW> for wxWidgets?
> 
>  I guess you missed "not" somewhere here.
> 
> JvdW> It clarifies and brings some order in things that are 
> JvdW> otherwise just put in the same place.
> 
>  Yes, there is an undeniable advantage in writing "wx::Window" instead of
> "wxWindow". Or is there? If there is, please describe it.

No that is a matter of preference. However when creating lots of widgets 
in a single function I could import the wx namespace and unambigously 
refer any widget in the namespace... The difference, besides the '::', 
is moment of choice. I agree it is a small thing.

Namespace hierarchies can categorise functionality while having small 
class/function names.

> 
> 
> JvdW> The failure to adopt modern C++ programming mechanisms
> 
>  This resembles marketing speak more than anything else. If you have
> concrete proposals, please speak up. If you don't, I don't really see the
> point of posting.

Let's start with namespaces again. Functions and classes that are not 
part of the interface of the library can be put in a separate nested 
namespace, that way they they will not likely cause conflicts with 
functions or classes that a user of the library defines. Of course you 
assume that the wx prefix already prevents this problem from ever 
happening.

One of the things I would consider a big improvement is stop using 
macros for generating data types and associated operations. Templates 
can solve the same problem, of course at the cost of compatibility with 
older compilers. Macro's work across namespaces and cause problems that 
can be extremely hard to track down. Last week I reported a conflict on 
the boost::thread mailing list between the wxWidgets introduced macro _ 
and the development version of boost::thread. A user of both libraries 
can be unnecessarily confronted with problems that are not their own.

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

Then there is exception handling for error propagation instead of 
passing through errors as return values of functions. An exception 
simply is not part of normal behaviour. So let handling of such 
exceptions have such a dominant effect of control flow? Guess this 
sounds too much like marketing again... The wxSocket* classes could use 
exception handling to report details about what when wrong.

Another popular request is to use signals/slots for event handling. But 
I would already be satisfied with a more flexible callback mechanism 
using functionality alike boost::function. It is so much more flexible 
because it also makes it possible to trivially associate arbitrary data 
with a specific handler, when required.

More of a general thought: I would like to see factory functionality for 
widget creation (to avoid memory issues). If widgets are allocated on 
the stack it will give problems at some point when the window to which 
they are attached is destroyed. I feel that a user should be protected 
from making such mistakes. Often such mistakes are expensive because 
they surface only in certain situations at runtime.

> 
> JvdW> I will not even consider joining the wxWidgets effort
> 
>  This is incredibly arrogant.

My point is that I'm not really inspired to contribute to the project no 
matter what I could offer the project. Despite the fact that I think the 
goal to be an admirable one. My views on how things should be done are 
simply far from how things are done at the moment. Judging from what I 
have read here and on the wiki I am not alone. It is a shame when people 
start their own projects with the same purpose (OMGUI) because they have 
a different view on how things should be done. I agree more with their 
approach but would rather want there to be a single effort: wxWidgets.

Also I have to admit that I really do not like programming GTK, QT, MFC, 
Carbon or any other platform specific framework. So that also limits my 
usefulness for a project such as wxWidgets. I can test and could try 
doing small bug fixes.

> 
> JvdW> What problem <does> wxWidgets solve? I want to build an application that 
> JvdW> works more or less the same everywhere (at least functionally the same). 
> 
>  wxWidgets is used in hundreds if not thousands of projects which do
> exactly this. The fact there are (and always will be) bugs doesn't mean
> that you can't use it for this. And obviously we do our best to fix such
> bugs as we find them, sorry if our efforts don't satisfy your expectations.
> Of course, we also rely on help from our users and we always appreciate
> efforts by people who do something to help wxWidgets. And we, or at least
> me personally, appreciate blanket statements of wxWidgets inadequacy
> without any constructive contributions behind them much less.

I respect this, it is an open source project and everyone does whatever 
possible to make it work. Same thing with our small toolset project. We 
do not listen to everyone that stands yelling at the sideline.

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

Regards,
Jeroen


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