WxWidgets 3.0: First Major Release in Several Years

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.

Comments

Some (in)equations

[fatphil]

2013 - 1998 = 15

Fifteen != Seven

Slashdot Editors != Editors

Re:Seven Years

[narcc]

Seven, of course.

Didn't you read the summary?

Re:Seven Years

[VZ]

This is my first ever submission to /. so maybe it's perfectly normal and I just have no idea how do these things work but I'm as puzzled as you because the original submission said "First Major Release in 15 years"...

Re:Is it still relevant?

[VZ]

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?

[LWATCDR]

I would say yes. Unlike QT it uses Native Widgets so it looks more like a native app than a QT or GTK app does. It was also pretty light weight as well. The fact that Audacidy uses it means that it is important enough. If you are a developer and are interested in multi platform it is really worth the time to explore.

Re:Is it still relevant?

[pjrc]

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.

But what does it really mean in practice?

[Shag]

If I'm parsing this all correctly, this is great news because it means I can port my graphical C++ (or whatever language, with hooks to C++) applications from Linux to Windows or OSX (or from Windows to Linux or OSX, or from OSX to Linux or Windows, whatever the case may be) without having to worry about UI widgetry.

Of course, unless my applications are already written in a language WxWidgets likes, and don't make any calls to other platform-dependent things (DirectX, I'm looking at you), this sounds like it makes my job a little easier, but not a whole lot. Admittedly, I haven't tried porting graphical apps across platforms before, so for all I know, getting the UI widgetry right could very well be 90% of the work.

I'm guessing I'm still going to need my platform-specific compilers/SDKs/IDEs on each platform for this all to feed into, as well. On the Mac side (the last place I built a graphical app, and that was several large cats ago) I'm a little unsure how using this with C++ or whatever is going to save me time over using Xcode with ObjC.

I welcome responses or thoughts on the pros and cons of all this, either from the WxWidgets folks themselves, or from other devs.

Re:But what does it really mean in practice?

[osu-neko]

Admittedly, I haven't tried porting graphical apps across platforms before, so for all I know, getting the UI widgetry right could very well be 90% of the work.

Yeah, writing the UI code is 90% of the work. Debugging it to work consistently across all platforms is the other 90%...

Re:But what does it really mean in practice?

[pjrc]

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:But what does it really mean in practice?

[pjrc]

I've build programs with wxWidgets 2.8. It does automatically handle those platform specific style issues!

I used wxMenuBar, populated with a heirarchy of wxMenu and wxMenuItem objects. I just pass a point to the main wxMenuBar object to SetMenuBar, which is from the top-level frame of the GUI.

On Mac OS-X, it automatically appear at the top of the screen. One Linux and Windows, it automatically appears on the top of my program's window.

Likewise for toolbars, I simply used with wxWidgets objects as documented, without any specific style stuff. They automatically adapt to fit the style of each system.

That's the magic of wxWidgets. That work you mentioned, adapting things to fit the stylistic expectation of each system, is exactly what wxWidgets does so very well. It's vastly superior to other toolkits which attempt draw their own widgets, because the wxWidgets developers have gone to tremendous effort to actually use the native widgets from each platform. You just use the rather generic API for wxWidgets and you end up with really good native GUIs on all 3 platforms. Best yet, when the user customizes fonts, colors and whatever else, your program adapts like other truly native applications. Other cross platform toolkits fall down in that respect to the customized style, because they aren't really using the platform's native GUI.

Trolltech's QT

[EmperorOfCanada]

I have wanted to love wxWidgets but I keep going back to QT. Now that QT is allowing you to port to Android and iOS I am not sure that I will ever take another crack at WX.

Other multi platform GUI'ish things that I like are OpenFrameworks (main complaint is that it runs hot) and cocos2d-x which allowed me to turf Objective-C on iOS.

Re:Seven Years

[twistedcubic]

Several != Seven

Too bad it's a C++ library...

[innocent_white_lamb]

There's nothing wrong with C++. However, I do my programing in C (without the ++), and would love have something like this available that I could link to my C programs.

GTK+ works fine in its way, but it moves way too fast for my taste. Function x is deprecated, use function y instead. Function y is deprecated, use function z along with function z(1) now. Ok, it's great that you're improving that thing, but not so great for a guy like me who wants to write an application today and use it for the next ten or twenty years without having to re-invent the wheel over and over again.

Since I have no particular desire to learn C++, I now do most of my programming using ncurses to handle the screen, keyboard and (occasionally) mouse. Ncurses is a Text-UI rather than a GUI, but just like the C language itself, it works very well,it hasn't changed in many years, and it suits me fine.

A slow-moving GUI like wxwidgets would be a wonderful thing to add to my toolbox, if it was a C library. *sigh*

Re:Too bad it's a C++ library...

[OldFart58]

If it was a C library... well, you couldn't really take advantage of all of the advantages C++ has vs C especially when implementing a windowing UI / application framework - inheritance, polymorphism, etc. really make a difference. If you did that in raw C you'd have, well - pretty much what we had to use for programming to the Win16 (now Win32) API before Borland's OWL (Object Windows Library) made the scene (this is before MS ever came up with MFC) - opaque handles to this and that, breaking down and handling Windows messages, etc. It was very low-level stuff, tedious and prone to error.

If you're happy with a CURSES-like library, that's fine (I've done my share of that also with C on DEC platforms, back in the VT-100 days) - but for anything this side of Y2K, application frameworks and OOP are the way to go. wxWidgets is definitely a valid way to get a cross-platform (and cross-language... look at wxPython) GUI app out there and still keep what's left of your hair.

Disclaimer: I've been using wxWidgets (was wxWindows) creating apps for a Fortune 500 international since the early 2.0 days (mid-90's).

Re:Too bad it's a C++ library...

[VZ]

I've never used it myself but there is wxC. AFAIK it's mostly used as a base for the bindings to the other languages (like wxHaskell), but perhaps it is good enough to be used directly.

You'll get used to it ...

[Taco Cowboy]

This is my first ever submission to /. so maybe it's perfectly normal and I just have no idea how do these things work but I'm as puzzled as you because the original submission said "First Major Release in 15 years"...

Don't worry, you'll get used to it

I have had my submits turned into articles that I don't even recognized ... ahh... what can I say, the /, editors like to think that they are magicians

This phenomenom has getting accutely troublesome especially _after_ Commander Taco has left

Re:You'll get used to it ...

[davester666]

Well, somebody has to add spelling and grammatical errors to the submission.

Re:A suggestion...

[Guy Harris]

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:Is it still relevant?

[Guy Harris]

What do they use it for? (No, "Google Earth" is not the correct answer; that's Qt-based.)

Google Drive, as per the wxWidgets home page, which says "The recently released Google Drive system desktop client uses wxPython."

Re:A suggestion...

[savuporo]

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.

Re:Is it still relevant?

[Lord Crc]

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:Seven Years

[gmhowell]

The irony is that while the readership complains about the lack of editing of submissions, as your story and others illustrate, those editors do far more harm than good when they bother to read/alter submissions.

Further (in)equations

[fyngyrz]

See, 7 is why we're fat. It's that whole two pi thing. We should be satisfied with one pi, but no, we have to have two. No wonder we're rounding up.

Mmm. Two (strawberry + key lime) pie.

Also, two (pizza) pie. Which is, strangely enough, the same as "pie pie."

Sufficiently large values of seven, indeed.

Re:A suggestion...

[brantondaveperson]

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?

[Lord Crc]

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.

Re:Hello world

[VZ]

You can reduce this to

#include <wx/wx.h>
 
struct MyApp : wxApp {
    bool OnInit() { wxMessageBox("Hello, world!"); return true; }
};
 
wxIMPLEMENT_APP(MyApp);

if you want, but this would just show you how to display "Hello, world" in a message box while the program at your link shows you a typical skeleton of a simple but realistic application. It doesn't try to be minimal, this is just not the point.