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

[Jeroen van der Wulp]

> 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,
> 
VZ>  Why should they be public at all? Currently such functions are declared
VZ> static inside the .cpp files (there we arguably should indeed use an
VZ> anonymous namespace for them but, frankly, nobody is going to notice 
this
VZ> anyhow).

I see, header-only implementations are still not on the map. Should have 
expected this, because the template mechanism is not being put to use.

VZ> The use of namespaces, while nice in theory, is just not worth it
VZ> in practice and doesn't really bring anything except the dubious moral
VZ> satisfaction.

The practical reason being that this-or-that old compiler does not 
support namespaces...

> 
> 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.
> 
VZ>  This is not the only cost. Another, often overlooked, one is much 
higher
VZ> compilation time (even with the latest and greatest compilers but
VZ> especially with the older ones).

I really do not care about how long it takes to compile wxWidgets. Do 
you have any idea how long it takes to compile QT on older machines with 
older compilers? My old laptop used to spend a day on it. wxWidgets 
compilation indeed does not even come close on the same machine (an hour 
maybe). I usually start compilation before I go to sleep, and the next 
day it is finished... For frequent building such as done by developers 
use a build system that is aware of header dependencies, supports 
modular building, and use the handle-body idiom to cut down compilation 
time.

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

As for embedded system compatibility, Java is phasing out the Java Micro 
Edition, in favour of the standard edition. Embedded devices are 
becoming more powerful in the future and decent C++ support will become 
available. We are still talking about the future of wxWidgets, not just 
the current version right...

The template mechanism can be used to parameterise interfaces to work 
with both the new and older macro based containers. Why still use the 
macros on systems that have a modern enough compiler and good STL 
implementation? I really have no choice here, some controls just just 
the macro based containers...

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

I assumed this already, because wxChar == char, and std::string can be 
converted automatically. Unfortunately if I use this feature my program 
does not work on a unicode build of wxWidgets. Template parametrisation 
of the string type in all interfaces could solve this problem.

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

I do not now about the details of GTK+ programming, and how wxGTK is 
implemented. I think that GTK+ returns error codes that at some point 
are passed back to a method in a wxWidgets component and from there the 
wxWidgets object hierarchy is all C++. The exception would only need to 
travels through C++ code. Or are there scenarios where C code actually 
uses wxWidgets components?

> 
> JvdW> Another popular request is to use signals/slots for event handling.
> 
VZ>  This is not really popular, at least it's about the first time I hear
VZ> about it. wx events dispatch code certainly has problems but at a first
VZ> glance boost::signal has even more of them.

Did I mention boost::signal explicitly? I would agree that it is not 
usable for wxWidgets in it's current form. It is possible though to 
design a version that is suitable for use in a future version of wxWidgets.

> 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.
> 
VZ>  Use wxEvtHandler::Connect().

I do but it is not flexible enough. Passing callbacks as function 
pointers will never be flexible enough for my purposes. If I want to 
associate arbitrary data with an event handler I have to introduce a 
class (a new name) that has to derive from wxObject to put this data in. 
Different data (different types) means a different class every time, 
unless perhaps I am willing to give up type-safety.

> 
> JvdW> More of a general thought: I would like to see factory functionality for 
> JvdW> widget creation (to avoid memory issues).
> 
VZ>  This is another wonderful idea (and not at all because of memory issues
VZ> but because it would allow to change the factory during run-time and 
also
VZ> mix native and universal widgets freely) which nobody really knows 
how to
VZ> implement.

I see that as an advantage as well, but I am not really interested in 
such functionality. What I fail to understand is that preventing users 
of the library from making mistakes has such a low priority. People make 
mistakes, even smart people. I think it is considered it to be a 
property of a good interface if it prevents (or makes it very hard) for 
a user to make a mistake.

> JvdW> Judging from what I have read here and on the wiki I am not alone.
> 
VZ>  Not alone in what? Saying that wxWidgets is not perfect? Totally so, we
VZ> all know pretty well about its shortcomings. And I'll even claim that I
VZ> know them better than any of the outsiders, just because I know more 
about
VZ> wx details.

Maybe, but are you a user of wxWidgets? The user perspective is often 
very different from that of the developer that knows the ins and outs. 
Using a tool is very different from creating it.

I thought we were discussing possible future improvement of wxWidgets. 
Indeed I meant that I'm not alone in thinking there should be lots of 
changes to wxWidgets in order to improve stability and usability of 
future versions.

 From a previous mail in this thread I found that a complaint is that 
all the people who propose such improments stick to the side line 
observing current development. I don't know if I'm alone on this one, 
but I am willing to do work on making the changes I propose a reality in 
some future version of wxWidgets. I just do not believe that there 
currently is any room for this.

An illustration of my previous point. Suppose I get an idea for an 
interface and write a new widget for all wxWidgets supported platforms 
and I use namespaces, exceptions and templates to parameterise the used 
string implementation, no matter how good it looks it will probably 
never get included (at least not without serious refactoring). It does 
not fit the current wxWidgets way of doing things.

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

I don't think that this situation can always be prevented. I think they 
have been experimenting with ideas for a next generation wxWidgets that 
may never come.

I get the feeling that there is no room for much change in wxWidgets. It 
is bound by backwards compatibility; guided by decisions to support 
exotic compilers/platforms and keep compile times within bounds on those 
platforms.  Or is it because there is not enough development time 
available to realise/maintain such changes? Don't get me wrong I do not 
want you to give up support of those platforms. But please do not ignore 
advances in C++/STL that have been available for many years on most of 
the other platforms because of it.

Occasionally I see Windows or GTK specific functionality being offered 
in the wxWidgets API. So wxWidgets does not stick to offering features 
on one platform that also exist on others. If there is this amount of 
adaption to a platform, why can't it be like that at the development 
level as well?

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

I'll do my best convincing the people around me that, that is the way to go.

I was thinking we were still talking about the next generation 
wxWidgets. I was hoping this meant the start of some ground breaking 
changes, a break with backwards compatibility. Many people do not like 
the MFC-ish look of the wxWidgets API because it does not properly match 
the other API's (can't testify on this one). I'm not saying that 
everything is done the wrong way in wxWidgets, but just that there is a 
lot of critique from a lot of people. If such critique (by more 
important people than me) is ignored for too long they may loose 
interest in the project. Just look at what happened at the Xfree86 project.

By the way I would love experimenting with any of the things I proposed 
above or in the previous email. For instance to parameterise the string 
implementation throughout all of wxWidgets. The reason is that those are 
things I believe to be steps toward a better wxWidgets. But there would 
have to be fair chance that the result is actually used.

> 
> JvdW> But if such consistency is not the goal of the wxWidgets project then
> JvdW> there is no point in doing the effort.
> 
VZ>  Any difference in behaviour between different platforms is by 
definition a
VZ> bug. As I said, nobody promises to fix all bugs but we certainly 
strive to
VZ> do it.

Good. I'm interested in structural improvements to the bug 
finding/fixing process. For graphical user interface frameworks it does 
not make much sense to do fully automated regression testing. How to 
reach the situation where such inconsistencies are systematically found 
and charted. Especially I would like the documentation to contain notes 
about known limitations per port (and possible workarounds until it is 
fixed in a subsequent version). I can try to make a project out of it. 
Any more ideas?

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