[wx-discuss] More wxTNG Discussion (was: aspects of a safe future)
Bryan Petty
> 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-...@lists.wxwidgets.org
For additional commands, e-mail: wx-disc...@lists.wxwidgets.org
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
Vadim Zeitlin
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++.
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.
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.
JvdW> I will not even consider joining the wxWidgets effort
This is incredibly arrogant.
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.
Regards,
VZ
Jeroen van der Wulp
> On Wed, 24 Oct 2007 16:23:38 +0200 Jeroen van der Wulp <J.v.d...@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
Vadim Zeitlin
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
Jeroen van der Wulp
> 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?
Vadim Zeitlin
JvdW> I see, header-only implementations are still not on the map. Should have
JvdW> expected this, because the template mechanism is not being put to use.
Please don't tell me that you'd like to put the entire code of wxWidgets
(2MLoC at the last count) in the headers.
JvdW> VZ> The use of namespaces, while nice in theory, is just not worth it
JvdW> VZ> in practice and doesn't really bring anything except the dubious moral
JvdW> VZ> satisfaction.
JvdW>
JvdW> The practical reason being that this-or-that old compiler does not
JvdW> support namespaces...
Actually, no. I don't think there are any compilers we use which don't
support namespaces (although plenty don't support ADL). The practical
reason is that we discussed this (look in wx-dev archives for details),
found that it would be difficult to do this in backwards compatible way and
that there are no obvious advantages in doing it anyhow. And so we decided
that our efforts would be better spent elsewhere.
JvdW> I really do not care about how long it takes to compile wxWidgets.
This is because you don't do it very often. I do, and I do care. And
obviously the templates would be in the headers and so this would affect
applications using wx as much as building wx itself.
JvdW> For frequent building such as done by developers use a build system
JvdW> that is aware of header dependencies, supports modular building, and
JvdW> use the handle-body idiom to cut down compilation time.
How exactly does it combine with putting all the code in the templates in
the header?
Again, I have trouble taking buzzword-ridden phrases such as above
seriously. If you have any concrete ideas to propose -- great. If not, this
discussion is really, really useless.
JvdW> I do not now about the details of GTK+ programming, and how wxGTK is
JvdW> implemented. I think that GTK+ returns error codes that at some point
JvdW> are passed back to a method in a wxWidgets component and from there the
JvdW> wxWidgets object hierarchy is all C++. The exception would only need to
JvdW> travels through C++ code. Or are there scenarios where C code actually
JvdW> uses wxWidgets components?
Yes. C callbacks call wx event handlers which in turn generate events
processed by the user code.
JvdW> I see that as an advantage as well, but I am not really interested in
JvdW> such functionality. What I fail to understand is that preventing users
JvdW> of the library from making mistakes has such a low priority. People make
JvdW> mistakes, even smart people. I think it is considered it to be a
JvdW> property of a good interface if it prevents (or makes it very hard) for
JvdW> a user to make a mistake.
Yes, I agree. But what mistakes exactly are we speaking about here
concretely?
JvdW> Maybe, but are you a user of wxWidgets?
Yes.
JvdW> An illustration of my previous point. Suppose I get an idea for an
JvdW> interface and write a new widget for all wxWidgets supported platforms
JvdW> and I use namespaces, exceptions and templates to parameterise the used
JvdW> string implementation, no matter how good it looks it will probably
JvdW> never get included (at least not without serious refactoring). It does
JvdW> not fit the current wxWidgets way of doing things.
It won't be included because it won't _work_. You can't use namespaces and
exceptions just in one control, this affects the entire library. As for
templates, you're free to use them as the svn trunk already does.
Finally, using parametrized string type is opposite to the development of
wxWidgets 3 where wxString is a superposition of std::string and wstring
and also supports UTF-8 so this is indeed unlikely to be acceptable. But
this still doesn't mean you can't use it (and interoperate with wx) in your
own code.
JvdW> I was thinking we were still talking about the next generation
JvdW> wxWidgets.
We talked about it enough, see all the previous wxTNG discussions. And
AFAIK nobody still has any precise idea just about anything, including all
the above mentioned issues such
- use of smart pointer-like objects instead of pointers
- better, type-safe, flexible event handling subsystem
- using factories for object creation
and many others. Just about the only issue which doesn't create any
problems is the use of namespaces -- which just proves that only trivial
changes not really bringing anything important are easy to do.
I'd love to have 6 months needed (in my estimation) to write a prototype
of wxTNG which would contain the answers to the questions above. But I
don't have enough time. And yes, it's true that wx may become irrelevant if
we never find the time to work on the new version. So it would be great if
instead of a single person spending 6 months we could have 12 persons
spending 2 weeks by working together. Except it doesn't seem to work like
this, as soon as there is more than 1 person much more time is spent in
discussions without ever arriving at anything.
JvdW> I was hoping this meant the start of some ground breaking
JvdW> changes, a break with backwards compatibility.
We can break with backwards compatibility only if wxTNG and current wx can
be used together and if you can progress to wxTNG progressively. We need to
find a way to allow it. Again, refer to the previous discussions for
wx2-on-3 and wx3-on-2 proposals.
JvdW> For instance to parameterise the string implementation throughout all
JvdW> of wxWidgets.
What exactly would this achieve?
Regards,
VZ
Jeroen van der Wulp
> On Fri, 26 Oct 2007 17:05:42 +0200 Jeroen van der Wulp <J.v.d...@tue.nl> wrote:
>
> JvdW> I see, header-only implementations are still not on the map. Should have
> JvdW> expected this, because the template mechanism is not being put to use.
>
> Please don't tell me that you'd like to put the entire code of wxWidgets
> (2MLoC at the last count) in the headers.
I never said anything about putting everything in header files.
Templates classes and methods can also be instantiated in cpp files. I'm
sure you know: when the type is not known at library compile time then
you want the template definition to be in the header file. And sometimes
for efficiency so code can be inlined.
> The practical
> reason is that we discussed this (look in wx-dev archives for details),
> found that it would be difficult to do this in backwards compatible way and
> that there are no obvious advantages in doing it anyhow. And so we decided
> that our efforts would be better spent elsewhere.
Makes sense. However, someone could offer to do it for you. With even
more macro magic it would be possible to make it backwards compatible.
Of course the result would be a maintenance nightmare, so it's better
not to do it at all. But should at some point you be making
non-compatible changes to a wxTNG (that still supports wx2) this
argument disappears so then you or someone else could introduce namespaces.
> Again, I have trouble taking buzzword-ridden phrases such as above
> seriously. If you have any concrete ideas to propose -- great. If not, this
> discussion is really, really useless.
What I meant is that compilation time can be controlled to some extend.
Through structuring the code itself or by having a smart enough build
system. So only a minimum amount of code needs to be recompiled to make
the library up to date. I did not want to go in detail about this. I
have not yet found the perfect build system that makes it all possible
without other problems.
It is no solution I am proposing, compilation time can still become
unacceptably high. As a result productivity may suffer. I have so far
felt that using templates for code generation has helped me get code
more compact and readable. For me this is enough compensation for the
discomfort of extended compilation time.
>
> JvdW> I see that as an advantage as well, but I am not really interested in
> JvdW> such functionality. What I fail to understand is that preventing users
> JvdW> of the library from making mistakes has such a low priority. People make
> JvdW> mistakes, even smart people. I think it is considered it to be a
> JvdW> property of a good interface if it prevents (or makes it very hard) for
> JvdW> a user to make a mistake.
>
> Yes, I agree. But what mistakes exactly are we speaking about here
> concretely?
Any mistakes in the use of that interface. The original quite concrete
context was to protect a user from allocation of widgets on the stack in
cases where wxWidgets will clean up that widget automatically.
But there are some more cases accidentally typing wxOK where wxID_OK was
meant, or vice versa. I will not get any warning from the compiler.
Also, giving the same identifier to different widget objects attached to
the same window.
I'm sure you are aware of these things and I do not want to dicuss
solutions. But I think we both agree that there is a way to help a user
find such mistakes before runtime. We apparently only disagree on how
important such issues are compared to other issues.
> - use of smart pointer-like objects instead of pointers
> - better, type-safe, flexible event handling subsystem
> - using factories for object creation
>
> and many others.
I know, I have read about it a couple of times. And I like many of the
suggestions. I noticed that so little of those ideas have so far
actually made it to version 3. But I realise that this is also related
to the available amount development time.
More hands get more work done. I will start filing bug reports, do I
really need a sourceforge account? The first may be about OpenGL support
not being found, or misreported by configure as not found (OS X with the
current development version). Or that it tries to import a header file
Quicktime/QuicktimeComponents.h that is not available for some reason.
But first I'll try to find a solution myself.
> JvdW> For instance to parameterise the string implementation throughout all
> JvdW> of wxWidgets.
>
> What exactly would this achieve?
Offering choice of string representation to the user of the library. As
I mentioned in a previous email, code that was written for an ANSI
variant of the wxWidgets libraries does not necessarily compile against
the unicode variant. If library variants can be merged, the compiler can
select the right string representation.
Your next question would be: what problem does this solve? It actually
only (partly) solves a distribution problem. The problem is that there
is no standard wxWidgets installation. Sometimes there is only the ANSI
build, sometimes only the UNICODE build. With wx3 it may also be the
UTF-8 build. We do not want to distribute wxWidgets as part of our
toolset so we rely on a version that the user installs or has
available. By the way the part it does not solve is that we use built-in
OpenGL support, and by default this support is not included when people
type ./configure .
Vadim Zeitlin
JvdW> > - use of smart pointer-like objects instead of pointers
JvdW> > - better, type-safe, flexible event handling subsystem
JvdW> > - using factories for object creation
JvdW> >
JvdW> > and many others.
JvdW>
JvdW> I know, I have read about it a couple of times. And I like many of the
JvdW> suggestions. I noticed that so little of those ideas have so far
JvdW> actually made it to version 3.
You should realize that we had used wx3 and wxTNG interchangeably in the
past. With UTF-8 changes it was decided to call the next version 3.0 and
not 2.10 because there are a few incompatibilities and this is a rather
major change. However wx3, as we will release it, has nothing to do with
wxTNG, it's just the continuation of wx2.
JvdW> > JvdW> For instance to parameterise the string implementation throughout all
JvdW> > JvdW> of wxWidgets.
JvdW> >
JvdW> > What exactly would this achieve?
JvdW>
JvdW> Offering choice of string representation to the user of the library. As
JvdW> I mentioned in a previous email, code that was written for an ANSI
JvdW> variant of the wxWidgets libraries does not necessarily compile against
JvdW> the unicode variant.
This is exactly the problem which is solved (albeit at a cost of not being
100% compatible and using quite a lot of implicit conversions under the
hood which may be a little confusing sometimes) in wx3.
JvdW> Your next question would be: what problem does this solve? It actually
JvdW> only (partly) solves a distribution problem. The problem is that there
JvdW> is no standard wxWidgets installation. Sometimes there is only the ANSI
JvdW> build, sometimes only the UNICODE build. With wx3 it may also be the
JvdW> UTF-8 build.
No. With wx3 there will be only one version, using either UTF-16/32 or
UTF-8 internally. But the interface will be the same.
Regards,
VZ
Jeroen van der Wulp
> On Fri, 26 Oct 2007 21:36:16 +0200 Jeroen van der Wulp <J.v.d...@tue.nl> wrote:
>
> JvdW> > - use of smart pointer-like objects instead of pointers
> JvdW> > - better, type-safe, flexible event handling subsystem
> JvdW> > - using factories for object creation
> JvdW> >
> JvdW> > and many others.
> JvdW>
> JvdW> I know, I have read about it a couple of times. And I like many of the
> JvdW> suggestions. I noticed that so little of those ideas have so far
> JvdW> actually made it to version 3.
>
> You should realize that we had used wx3 and wxTNG interchangeably in the
> past. With UTF-8 changes it was decided to call the next version 3.0 and
> not 2.10 because there are a few incompatibilities and this is a rather
> major change. However wx3, as we will release it, has nothing to do with
> wxTNG, it's just the continuation of wx2.
That clarifies some things. I was under the impression that it was
decided that wxTNG was no longer the right course and that wx3 would
just be more of the same as wx2 but with better unicode support.
>
> JvdW> > JvdW> For instance to parameterise the string implementation throughout all
> JvdW> > JvdW> of wxWidgets.
> JvdW> >
> JvdW> > What exactly would this achieve?
> JvdW>
> JvdW> Offering choice of string representation to the user of the library. As
> JvdW> I mentioned in a previous email, code that was written for an ANSI
> JvdW> variant of the wxWidgets libraries does not necessarily compile against
> JvdW> the unicode variant.
>
> This is exactly the problem which is solved (albeit at a cost of not being
> 100% compatible and using quite a lot of implicit conversions under the
> hood which may be a little confusing sometimes) in wx3.
I'll have a look and see how it works out.
About the STL support. I checked 2.8.5 and 2.9.0, and both work fine on
OS X. I also checked 2.8.6 with MSVC 2008 beta2 and that seems to works
as well. I was quite disappointed before because I did not get it to
work on several occasions. I was starting to think that STL integration
had a very low priority. I have already modified our tools so that they
compile against versions of wxWidgets with STL support.