News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

wxWidgets 3.0.0 released!

Started by ollydbg, November 12, 2013, 01:02:41 AM

Previous topic - Next topic

ollydbg

From http://www.wxwidgets.org/

QuoteNew Stable Major wxWidgets 3.0.0 Release
2013-11-11

The final version of wxWidgets 3.0, the first new stable wxWidgets release in years and the first new major release since 1998, is now available. Please download the sources and binaries for the selected Windows compilers (Microsoft Visual C++ and MinGW-TDM) from SourceForge or our FTP mirror. As usual, the release files contain the sources and the documentation for the library in Unix (.tar.bz2) and Windows (.zip or .7z, with the latter being significantly smaller) formats. Notice that the documentation is also available online.

3.0 release is a culmination of several years of work since 2.8 and so brings many important improvements compared to the old stable series, such as much better and simpler to use support for Unicode, the new wxOSX/Cocoa port, suitable for development of 64 bit GUI applications under OS X, and support for GTK+ 3 in wxGTK port, as well as a huge number of other new features and bug fixes which are too numerous to be listed here, so please refer to the change log for the full list. And if you're upgrading from a previous version, please pay special attention to the "incompatible changes" section of this file and the changes chapter of the manual for even more details.

We hope you will enjoy using the latest and greatest version of wxWidgets! And if not, there is always the possibility to report bugs in it on our bug tracker. Have fun and good luck!

Also some binaries files include binaries files build from TDM4.7.1 and TDM4.8.1, both 32bit and 64bit, debug version and release version which are contributed by our forum user: Xaviou.

See: https://sourceforge.net/projects/wxwindows/files/3.0.0/binaries/

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Alpha

Yes!  It is out!

(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)

oBFusCATed

Quote from: Alpha on November 12, 2013, 04:12:17 AM
(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)
We don't recommend it, building C::B against wx30 is only for people who like to port C::B to wx30...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ptDev

At the very least, the wxWidgets project wizard should be updated.

oBFusCATed

Quote from: ptDev on November 12, 2013, 10:14:38 AM
At the very least, the wxWidgets project wizard should be updated.
There is a patch provided here: http://forums.next.codeblocks.org/index.php/topic,18460.0.html
It would be good if interested people test it and report if it is working or not...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Alpha

Quote from: oBFusCATed on November 12, 2013, 07:50:35 AM
Quote from: Alpha on November 12, 2013, 04:12:17 AM
(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)
We don't recommend it, building C::B against wx30 is only for people who like to port C::B to wx30...
Well, working on porting was my intent.
(From what I can tell Code::Blocks expects wxWidgets to be multi-lib under Linux.)

Jenna

Quote from: Alpha on November 12, 2013, 02:45:25 PM
Quote from: oBFusCATed on November 12, 2013, 07:50:35 AM
Quote from: Alpha on November 12, 2013, 04:12:17 AM
(Do we yet have a recommended set of configure flags when building wx30 to build Code::Blocks against?)
We don't recommend it, building C::B against wx30 is only for people who like to port C::B to wx30...
Well, working on porting was my intent.
(From what I can tell Code::Blocks expects wxWidgets to be multi-lib under Linux.)
That's the default in all distros I know.
If you need wxWidgets build-flags for linux, I can post the configuration I use to build wxWidgets for C::B on my Fedora system later this day.

oBFusCATed

Quote from: Alpha on November 12, 2013, 02:45:25 PM
(From what I can tell Code::Blocks expects wxWidgets to be multi-lib under Linux.)
On linux I don't think we depend much on multilib vs monolithic, because wx-config should handle the differences for us.

I use the defaults configure flags, they work rather well (I can build C::B with them at least).
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Alpha

With --enable-monolithic I have to tweak the project file, otherwise it errors at not being able to find the aui and propgrid libraries.  With --disable-compat28 --with-gtk=3 Code::Blocks builds fine, but will definitely be needing some bug fixing before it is useable ::).

ollydbg

Question about build C::B under Windows (32bit) against wx3.0.0. Is Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks still the guide?

I just download the pre-build binaries (wxMSW-3.0.0_gcc471TDM_Dev.7z and wxWidgets-3.0.0_headers.7z) from official wx site, but I found that if was build with multi-libs, not the usually way I build wx2.8.12 in monolithic lib.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

gd_on

#10
Is Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks still the guide?
I don't think so. I have built it exactly as I build wxWidget 2.8.12 because with the switch USE_STC=0, I obtained compiling errors in the wxWidget build process.
So, my command line is :
Quotemingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 USE_OPENGL=1 VENDOR=cb CXXFLAGS="-fno-keep-inline-dllexport" >log.txt 2>&1

Like that, it's OK.

look also in : http://forums.next.codeblocks.org/index.php/topic,18412.msg125957.html#msg125957

gd_on
Windows 11 64 bits (25H2), svn C::B (last version or almost!), wxWidgets 3.3.2, Msys2 Compilers 16.1.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

cacb

General question relating to wx3.0 and Code::Blocks: Is wxSmith "fully compliant" with wxWidgets 3.0, i.e. are there any known problems?

I use wxSmith quite a lot, and I am in the process of upgrading to wx3.0. Can I assume that wxSmith+wx3.0 will be working well?

oBFusCATed

Quote from: cacb on December 10, 2013, 01:04:52 PM
Can I assume that wxSmith+wx3.0 will be working well?
Of course you can't. We're not advertising it as such. Test it on your dialogs and report problems if you encounter any.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

cacb

#13
Quote from: oBFusCATed on December 10, 2013, 01:23:19 PM
Quote from: cacb on December 10, 2013, 01:04:52 PM
Can I assume that wxSmith+wx3.0 will be working well?
Of course you can't. We're not advertising it as such. Test it on your dialogs and report problems if you encounter any.

That's not a helpful reply. Sorry if my question was not clear. Perhaps this is clearer: Are there significant known problems in this area?

I will of course report anything I find, but I was hoping to avoid finding+reporting already known problem in this area, if any.

ollydbg

Hi, I would like to change the page title of wiki Compiling wxWidgets 2.9.0 to develop Code::Blocks (MSW) - CodeBlocks
To some kind of "Compiling_wxWidgets_3.0.0_to_develop_Code::Blocks_(MSW)", not sure how to do it in wiki, but I'm staring now.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.