Will be wxWidgets 3.0 ever released?
Kolya Kosenko
I looked at the release roadmap and find out interesting statistics.
http://trac.wxwidgets.org/wiki/Roadmap
Here is release plan changes and related hopes:
2009-Jan-12: "We hope to make 3.0 before the end of 2009" (12 months
later)
2009-Sep-29: "We hope to make 3.0 in the first half of 2010" (10
months later)
2010-Jul-18: "We hope to make 3.0 before the end of 2010" (6 months
later)
2010-Dec-20: "We hope to make 3.0 in the spring of 2011" (6 months
later)
2011-Jul-05: "We hope to make 3.0 at the end of 2011" (6 months later)
2011-Nov-03: "We hope to make 3.0 in the spring of 2012" (7 months
later)
2011-Dec-14: "We hope to make 3.0 in the summer of 2012" (9 months
later)
Windows 8 will be released in the summer of 2012 and GSoC 2012 project
will require attention in middle and the end of the next year.
This probably require next release delay and in July 2012 will be
announced that 3.0 will be at the end of 2012? And at the end of next
year will be announced that release will be in the spring of 2013? And
so on.
There is a lot of new amazing widgets in 2.9.3 release, but why 2.9.3
release is not called 3.1.0 one?
There is plans about GTK+3, wxOSX 64-bit. But in January 2009 this
goals will not seems to delay 3.0 release?
I known that 3.0 will be released a.s.a.p. but 3 years delay is not
looks like so soon as possible.
Regards,
Kolya
Vadim Zeitlin
KK> There is a lot of new amazing widgets in 2.9.3 release, but why 2.9.3
KK> release is not called 3.1.0 one?
Because we want to have decently working wxOSX/Cocoa in 3.0. If we can't
get it, we'll release 3.0 without it but it would be a pity. So I still
hope that more people interested in using native Cocoa controls in their
cross-platform applications can be found and convinced to help because
clearly there is too much for a single person there.
I just looked at http://labs.qt.nokia.com/2011/12/15/qt-4-8-0-released/
today and the part that really attracted my attention was not the list of
changes but rather the pictures of people who have participated in the
release. I didn't count the number of them in the photos but there seems to
be a couple of *hundreds* of them. Even if many (most?) of them work on
documentation, testing or something else this is still pretty humbling as
we had 11 committers with more than 1 check in (and 3 more with exactly 1)
since the previous release. And even considering that dozens of people
helped with bug reports and patches, it still doesn't make up for the
numbers (especially as outsiders probably contribute to Qt as well). And
don't forget that none of those dozen committers works on wx even close to
full-time unlike all of those Qt people.
So we clearly need more people and more help. We do what we can but there
is only so much that can be done this way.
KK> There is plans about GTK+3, wxOSX 64-bit. But in January 2009 this
KK> goals will not seems to delay 3.0 release? I known that 3.0 will be
KK> released a.s.a.p. but 3 years delay is not looks like so soon as
KK> possible.
This is why I keep telling people that they should just use 2.9.3 instead
of waiting for 3.0. There will be nothing magic about 3.0, no bugs will get
suddenly resolved just because we increment the major version number.
Anyhow, to answer your question: yes, 3.0 will be released. I don't know
when but I do think we should do it in 2012 even if neither wxGTK3 nor
wxOSX/Cocoa are ready. This will be unfortunate but at the current stage
there is really nothing I personally can do about this.
Regards,
VZ
Ed Musgrove
> -----Original Message-----
> From: Vadim Zeitlin
>
> This is why I keep telling people that they should just use 2.9.3 instead
of waiting for
> 3.0. There will be nothing magic about 3.0, no bugs will get suddenly
resolved just
> because we increment the major version number.
I fully understand your desire to hold off on bumping the revision number
until...but...
[disclaimer] As I have pointed out before, while I am not a formal member of
the Audacity Development Team, I do a lot of QA for them and am a member of
the Audacity Manual Editors. I also have had quite a few patches applied in
the effort of fixing bugs over the last 2+ years.
The Audacity developers are unwilling to move to 2.9+ for (at least) two
reasons, the first is the obvious major changes in the wx API (last month I
spent many, many hours porting Windows Audacity from wx2.8 to wx2.9 (got it
to compile but not run yet). A second reason is that in our compile/link
scripts (VC++ projects, make files etc. of which there are a huge amount) we
have references to wxbase28u_net_vc_custom.* and the other various libraries
and their unicode/non-unicode flavors. If we want to progress from wx 2.8.11
to wx 2.8.12 those library names do not change but if we go to 2.9+ they
change (wxbase29u_net_vc_custom.* etc.). In a
cross-platform/multiple-compiler application like Audacity there is no
simple "search & replace" solution for changing the many hundreds of library
names. It will take a huge effort for any big application to convert to
*29*.lib/dll names only to have to convert to *30*.lib/dll names when you do
change.
I realize the library names must change when the API changes but you must
realize that it is not always a trivial job for us wx users to move up to a
new version number! Great job, BTW; my hat is off to you! I created a
similar (though much less feature-ridden) library for BeOS and I know that
the job y'all do is astonishing.
--Ed
Vadim Zeitlin
EM> The Audacity developers are unwilling to move to 2.9+ for (at least) two
EM> reasons, the first is the obvious major changes in the wx API
No more major (or even minor) changes to the API are planned until 3.0 so
this shouldn't be a concern. It's only the ABI that is not fixed yet. I
think we really shot ourselves in the foot with the stable/development
releases nomenclature as it clearly prevents people from using 2.9, we
should have never used it :-(
EM> A second reason is that in our compile/link scripts (VC++ projects,
EM> make files etc. of which there are a huge amount) we have references to
EM> wxbase28u_net_vc_custom.* and the other various libraries and their
EM> unicode/non-unicode flavors. If we want to progress from wx 2.8.11 to
EM> wx 2.8.12 those library names do not change but if we go to 2.9+ they
EM> change (wxbase29u_net_vc_custom.* etc.). In a
EM> cross-platform/multiple-compiler application like Audacity there is no
EM> simple "search & replace" solution for changing the many hundreds of
EM> library names. It will take a huge effort for any big application to
EM> convert to 29.lib/dll names only to have to convert to 30.lib/dll names
EM> when you do change.
I hate to say it but if it's really difficult to upgrade wx version in
your build system you're doing it wrong. Under Unix there should be no need
whatsoever to hardcode the version as you ought to be using `wx-config
--libs` anyhow. Under Windows you should be using either MinGW with
configure (so same as under Unix) or MSVC in which case the *only* setting
you need to update is the include path to include/msvc directory, nothing
else needs to be touched.
EM> I realize the library names must change when the API changes but you must
EM> realize that it is not always a trivial job for us wx users to move up to a
EM> new version number!
It really shouldn't the case. Streamline your project/make files even if
you remain with 2.8 for now, you won't regret it.
Regards,
VZ
Ed Musgrove
files! Maybe after Audacity releases its imminent 2.0 stable version I will
try to get some help to do this streamlining--thanks!
--Ed
> -----Original Message-----
> From: Vadim Zeitlin
>
> On Thu, 15 Dec 2011 15:09:14 -0800 Ed Musgrove wrote:
>
> EM> A second reason is that in our compile/link scripts ...
> EM> It will take a huge effort ...
> EM> to convert to 29.lib/dll names only to have to convert to 30.lib/dll
> EM> names when you do change.
>
> I hate to say it but if it's really difficult to upgrade wx version in
your build system
> you're doing it wrong.
>
> EM> I realize the library names must change when the API changes but you
> EM> must realize that it is not always a trivial job for us wx users to
> EM> move up to a new version number!
Paul Cornett
> Under Windows you should be using
> either MinGW with configure (so same as under Unix) or MSVC in which
> case the *only* setting you need to update is the include path to
> include/msvc directory, nothing else needs to be touched.
With MSVC, how are they supposed to link with the wx libraries without
giving their names?
Robin Dunn
msvc/wx/setup.h has pragmas that name the libs that should be
automatically linked.
--
Robin Dunn
Software Craftsman
http://wxPython.org
Pikin Sergey
>
> msvc/wx/setup.h has pragmas that name the libs that should be
> automatically linked.
>
I just wonder: why isn't it used in samples?
Vadim Zeitlin
PS> > msvc/wx/setup.h has pragmas that name the libs that should be
PS> > automatically linked.
PS>
PS> I just wonder: why isn't it used in samples?
Because the samples need to be compiled with any compiler, not just MSVC
one. And because it's actually simpler to generate the makefiles for the
samples with the library names using bakefile as this is what it does by
default.
Regards,
VZ
Ed Musgrove
I know this is a newbe question but I have to learn somehow...
The app links to these wx dependencies:
wxbase28.lib wxbase28_net.lib wxmsw28_adv.lib wxmsw28_core.lib
wxmsw28_html.lib wxexpat.lib wxpng.lib wxzlib.lib wxjpeg.lib wxtiff..lib
and theses DLLs:
wxbase28_net_vc_custom.dll
wxbase28_vc_custom.dll
wxmsw28_adv_vc_custom.dll
wxmsw28_core_vc_custom.dll
wxmsw28_html_vc_custom.dll
Looking at \wxWidgets-2.8.12\include\msvc\wx\setup.h I see various:
#pragma comment(lib,"wxbase28ud")
What is the best place to include this msvc\wx\setup.h file (does it need to
precede all other wx or app specific headers or anything like that)?
How do I change my MS VC++ Express projects which currently specify
wxbase28.lib (etc.) so that they pick up the current version?
What about the DLLs, will that just work?
--Ed
Vadim Zeitlin
EM> Looking at \wxWidgets-2.8.12\include\msvc\wx\setup.h I see various:
EM> #pragma comment(lib,"wxbase28ud")
EM>
EM> What is the best place to include this msvc\wx\setup.h file (does it need to
EM> precede all other wx or app specific headers or anything like that)?
Yes, as I wrote *all* you need to do is to ensure that $WX/include/msvc
directory appears in your include path before $WX/include. In particular,
you must *not* explicitly include this file.
EM> How do I change my MS VC++ Express projects which currently specify
EM> wxbase28.lib (etc.) so that they pick up the current version?
Don't change them, remove them completely.
EM> What about the DLLs, will that just work?
Yes.
Regards,
VZ
Ed Musgrove
configurations I opened the Properties page and changed the Additional
Include Directories (Configuration Properties, C/C++, General panel) such
that
"$(WXWIN)\include\msvc\wx";
was added as the very first item.
In the Configuration Properties, Linker, Input panel for every projects'
configurations I removed all wx*.lib references.
I Cleaned via Batch Build the entire solution then did a Build All (normally
this will result in all 100 Builds succeeding with no errors). The result is
80,000+ of this kind of linker error:
ScripterCallback.obj : error LNK2001: unresolved external symbol
"__declspec(dllimport) char const * const wxEmptyString"
(__imp_?wxEmptyString@@3PBDB)
What am I missing? I am using MS VC++ 2008 Express.
--Ed
> -----Original Message-----
> From: Vadim Zeitlin
>
> On Fri, 16 Dec 2011 13:07:50 -0800 Ed Musgrove wrote:
>
> EM> Looking at \wxWidgets-2.8.12\include\msvc\wx\setup.h I see various:
> EM> #pragma comment(lib,"wxbase28ud")
> EM>
> EM> What is the best place to include this msvc\wx\setup.h file (does it
> EM> need to precede all other wx or app specific headers or anything like
Dimitri Schoolwerth
<edgarm...@wavecable.com> wrote:
> I must not understand. In the various Audacity projects' all four
> configurations I opened the Properties page and changed the Additional
> Include Directories (Configuration Properties, C/C++, General panel) such
> that
> "$(WXWIN)\include\msvc\wx";
> was added as the very first item.
As mentioned, try "$(WXWIN)/include/msvc". That's without the trailing wx part.
Regards,
Dimitri
Ed Musgrove
just fine--other configs building now.
Thanks to all for setting me on the right track.
--Ed
> -----Original Message-----
> From: Dimitri Schoolwerth
>
> On Sat, Dec 17, 2011 at 6:03 AM, Ed wrote:
> > I must not understand.
>
tonda...@post.cz
WXVER = 29
wxbase$(WXVER)u.lib wxmsw$(WXVER)u_gl.lib
Moreover I use both 32 and 64 bit builds, so I have one more macro for it.
I use makefiles on both Linux and Windows, they are easier to maintain.
TonyMi
> ------------ Původní zpráva ------------
> Od: Ed Musgrove <edgarm...@wavecable.com>
> Předmět: RE: [wx-dev] Will be wxWidgets 3.0 ever released?
> Datum: 16.12.2011 22:08:08
> ----------------------------------------
> --
> To unsubscribe, send email to wx-dev+un...@googlegroups.com
> or visit http://groups.google.com/group/wx-dev
>
>
>