OSNews

wxglade a layout an throw it into VC, do the callbacks and your're "done"

This works only if your app uses nothing more than the common controls. Any non trivial application requires subclassing widgets, implementing new funtionality, etc. That's done by hand, no gui builder can help you. Then you face all of wxWidgets API ugliness.

Doing that is a nightmare in wxWidgets. Why do you think it has never really caught? wxWidgets have been around for ages (first version was for Windows 3.1). Why do you think many others have created other toolkits? Its API is ugly and it is very difficult to extend (due to the way it is designed, as a layer on top of other toolkits). To add a new widget to wxWidgets I need to be a WIN32/MFC programmer, a gtk+ programmer and a Cocoa programmer (which, incidentally, means I should know C++, C, and Objective-C) and then maintain 3 codebases. Not nice.

With any modern toolkit those hacks you suggest to reach threadsafety are not required. This is an example of what I said before: wxWidgets is a low productivity environment. You need to implement every time things that should be a part of the library.

That's also the reason there are not third party widgets to wxWidgets. Compare with what is available for Java/Swing, MFC or even Qt.

WxWidgets is slower than MFC or gtkmm (which are comparable libraries). U++ or Qt are not, because they are not wrappers, they are implemented using a low level API. Granted, this is not such a big issue these days of multi-Ghz machimes and GBs of RAM, but it may still be noticeable in a complex interface.

Incidentally, this also means I can create a new widget with U++, Qt or Swing with ease. I don't need to know any other API besides what each one of them provides. Compare this with wxWidgets or SWT.

The ugly comment was about the design of the library, not its look and feel. Although its look and feel isn't entirely native, as it needs to play with the geometry of widgets to achieve its cross-plattform compatibility goal.

The license does not allow those of us who can contribute to such a library to reuse the code. If you are only interested in using the library that is not an issue, but if you are going to examine its internals, to study the code, and to contribute to the library it would be nice that you could copy and paste any snippet of code you found there for your own projects. The LGPL (with or without static linking extensions) thwarths reusability. If I'm going to put the effort that it takes to familiarize myself with the internals of a library I'd rather work with BSD-licensed code that I can reuse without problems.

Thanks for the reply, rover. You have some valid points about wxWidgets (re: very old, MFC-like design, hard to extend). That said, there are two things I'd like to point out:

1: It's not BSD, but it's basically MPL (read the exception!); what's wrong with that? If you change the library ITSELF you have to publish the changes, but if you add another layer on top, you're free to link wx to it with absolutely no strings attached; license it with whatever license you want. Heck, if you want to make a proprietary extention, all you have to do is publish the hooks, and the extension (which could be a custom control) is yours to sell and restrict as you please.

To be fair, you might not be able to copy and paste snippets from quasi-MPL'ed wx to your program without MPL'ing your program (an issue I hadn't considered), but for small snippits, it shouldn't be a problem to just rewrite that small section. Either that or make it an island upon itself and staticly link it to your program, hence only having to reveal what you cut and paste in the first place.

2. One man's minus is another man's plus. One of the main reasons I'm using wxWidgets on my small/medium-ish program (15000 lines so far, and it's still in beta) is precisely because it uses native widgets on each platform. I'll take slightly slower native widgets than faster non-native widgets any day. The only toolkit I've seen that looks good non-native is Qt (and of course, it *is* native on KDE ), and that has tons more licensing problems for an independent developer like me than wxWidgets.

It really does do its best to look good on each platform. Make an "Fire/Exit" menu item, and wx *automatically* moves it to the correct place on OS X. Ditto with "Help/About"; heck, it deleted the "Help" top-level menu when it saw it was empty after moving "About" to its OS X location. And it subtly alters spacing and such on each platform to make it look more native. My only complaint so far is how it handles tabs and sliders.

(Not to start any flame wars or anything, but albeit a couple of years ago, the toolkit that looked the absolute worst to me was FLTK , and it drew its own widgets. One of the prime reasons I chose wxWidgets this time around was the memory of how bad non-native can look!)