WxWidgets 3.0: First Major Release in Several Years 147
First time accepted submitter VZ writes "The first new stable wxWidgets release in years and the first new major release since 1998 has just been announced. wxWidgets 3.0 now includes official support for Cocoa-based 32 and 64 bit applications under OS X, GTK+ 3 under Unix and has thousands of other improvements."
Update: 11/12 01:00 GMT by U L : Clarification: it's been several years since the 2.8 release series, and fifteen years since wxWidgets 2.0.
Re:Is it still relevant? (Score:5, Informative)
The main reasons to prefer wx to Qt remain the same as always:
1. Native widgets (especially important under OS X).
2. Written in 100% standard C++ (no compiler-specific extensions, no preprocessor).
3. More permissive licence (notably allowing static linking for non-open source applications).
And then there is wxPython which is quite popular in Python community.
Re:Is it still relevant? (Score:5, Informative)
I use wxWidgets. I've mostly used verson 2.8 with ansi strings.
As far as I know, wxWidgets is the only cross platform toolkit that compiles to program that use the native GUI widgets on Windows, Mac and Linux.
You can usually spot Java and QT programs. They work, but things look a little out of place. Firefox does a better job, but things start going wrong if the user customizes or "themes" their desktop. Emulating the look of native GUI controls just isn't ever as good as actually using the native ones.
wxWidgets isn't perfect. I've hit a good number of bugs. It has a pretty steep learning curve. It also doesn't seem like "new" technology. But it works. If you want to write a native application that truly looks and feels and actually is native on each platform, short of writing the code 3 times, wxWidgets is pretty much the only toolkit.
Re:A suggestion... (Score:5, Informative)
Sounds like a different implementation that does the same thing as QT.
Not exactly. Both Qt (not QT) and wxWidgets are cross-platform, but wxWidgets uses native widgets wherever possible (as their home page says, "Unlike other cross-platform toolkits, wxWidgets gives its applications a truly native look and feel because it uses the platform's native API rather than emulating the GUI."), whereas Qt primarily uses its own widgets.
Re:But what does it really mean in practice? (Score:5, Informative)
I use wxWidgets. Most of my experience is with version 2.8.
If you care deeply about making a native applcation that truly has a native GUI on Windows, Mac and Linux, wxWidgets is great. Nothing else even comes close. Java, QT, XUL, FLTK, TCL/KT and others all produce programs that aren't quite right on some plaforms.
If you don't care about cross platform native GUI applications, or you target browsers with javascript+node+[insert newest buzz], then wxWidgets is not for you. If you really only want to produce a program for Windows but maybe someday have the option to easily port to Mac and Linux, while wxWidgets can give you that, if you don't truly care are doing all 3 from the beginning, I believe you'll find wxWidgets it simply too much trouble.
The truth is wxWidgets is pretty much its own system, an SDK in itself. It has a tremendous amount of somewhat complex design, like sizers, which means you have to go to some extra effort. Of course, for making things work well on all platforms... not simply just work, and not work well on Windows but end up sub-standard on Mac or Linux, but work truly well on all 3, the extra effort to use wxWidgets is definitely worthwhile.
But the truth is you do have to put in extra effort. wxWidgets has great documentation to help, but the other truth is everything is heavily steeped in C++ class heirarchy. If you're good with C++, it'll feel pretty natural. If not, well, you'll get much better with C++ in the process, if you persevere. In the end, if your goal was a native application that truly works natively on all 3 platforms, the sort of thing users take for granted and never notice, you'll be rewarded.
But if you don't really, truly, earnestly care about targeting all 3, if only Windows has to be high quality and the others are afterthoughts, or if you just want to get things done as quickly as possible with minimal learning, you'll probably find wxWidgets to be far too much trouble.
Re:Is it still relevant? (Score:5, Informative)
1. Native widgets (especially important under OS X).
Ironically this is the reason we moved our cross-platform OSS app away from wxWidgets to Qt. The native widgets just didn't work properly and it was a pain to fix. We made the move some 4 years ago or so, and I can't say we've noticed we're missing something...
Re:A suggestion... (Score:1, Informative)
And Qt is not really C++ as it relies on MOC.
Its about time for a GUI toolkit that actually fully leverages what C++11 has to offer.
C++11 is not even supported on most of the target compilers yet. And you can use c++ for signals/slots these days without string intermediaries.
http://qt-project.org/doc/qt-5.1/qtcore/qobject.html#connect-4 [qt-project.org]
MOC just generates some signals/slots boilerplate code, which is C++ code. You might as well bitch that UIC is not C++ either because it generates C++ boilerplates from XML.
PS. the moderators utterly fail - the parent is neither informative nor correct. oh well. I guess I and everyone at Trolltech/Nokia/Digia didn't know they wasn't using c++ for last 10+ years.
Re:A suggestion... (Score:5, Informative)
I see what you mean, but nevertheless when editing Qt code, one sees additional keywords that do not appear in the C++ standard. The fact that these keywords are pre-processed by a special compilation step into C++ code does not make the code you actually edit standard C++. I think this is an important distinction.
Also, Qt has its own notions of strings and files and threads and what-have-you. Once Qt is in your code, you ain't getting it out.
Re:Is it still relevant? (Score:4, Informative)
Some users really want the perfect look of native widgets
Yeah, I get that. But given than the OSX offering from wxWidgets was pretty much broken on a constant basis, not-quite-native-but-functional Qt widgets won the day over broken-every-other-week wxWidgets.
I exaggerate slightly, but the lack of proper OSX support was the main driver to Qt for us.