…just another hippy blog

42 is the answer to life, the universe and everything. But today’s question is: “why do I hate wxWidgets?”

Long time no post, I know. I’ve been pretty busy these last weeks, sorry.
Ok. I am not going too far with this cheap excuse - I’ve been just too lazy these weeks.

Nevertheless, there are some topics I really wanted to talk about. Please take some advice and don’t blame me if I’m being cynical one more time.
That’s the way I am

Today’s subject: wxWidgets
Abstract: wxWidgets suck
Conclusion: I won’t touch wxWidgets again

wxWidgets is one of the most complete and interesting cross platform GUI frameworks. Btw. there should be another name for this kind of libraries, as they do far more than just GUI components.
This is why I should not say they “suck”… in fact, there’s a few things I really don’t like in wxWidgets.

PS: I will take the latest stable release into account in this post: 2.8.0, released 2006-12-12.

The first time I tried to deal with wxWidgets was about one or two (say two) years ago.
I was trying the CodeBlocks IDE on Bill’s O.S. (is “Bill” a registered trademark too? I really hope I didn’t infringe any patents by writing His name!) but it lacked of some very important feature (I really don’t remember what it was exactly about).
This is the reason I tried to mess with the CodeBlocks source code.
Note for dummies: yes, CodeBlocks is written in C++ and it uses the wxWidgets framework.
I didn’t go far with the CodeBlocks source code, but the main reason is that I had to deal with a part of the IDE’s source code that IMHO had not been designed very well, so it would have been a P.I.T.A. to implement the feature I was looking for. And besides that, I found that other IDEs could fulfill my requests better than CodeBlocks.

CodeBlocks apart, this has been the first time I managed to see what wxWidgets was all about.

My second (and hopefully last) opportunity has been when I had to write a custom widget for a Computer Graphics lab assignment at the University of Pisa, where I am still trying to get a (presumably worthless) master’s degree in CS.
The task: writing a widget that could display images, allowing the user to drag and resize them using the mouse and to zoom the view in or out.
IOW a trivial graphics view.

Here are my main “complaints” about wxWidgets:

1. They are supposed to be platform-independent (read “write once build one milion times”, just like Qt or GTK) but they are a real P.I.T.A. in fact.
2. The API is a mess. “Consistency” is not part of wxWidget’s vocabulary.
3. The whole wxWidgets source code needs a deep (really deep) update - it’s a real mess right now.
4. The documentation has some serious issues.

Ok, here comes my opinion about the above four points.

Number one.
There are a few issues related to platform independence. I’ve experienced a different rendering behaviour on Linux and Windows and this is quite upsetting.
This is not a good thing because the framework is supposed to be platform independent. If you read the reference documentation, you may also realize that lots of API calls have platform dependency problems.
The framework’s design is not the best I have seen and the APIs reflect this problem. Just to make an example, you might have to chose between three or more different “painter” objects: wxBufferedDC, wxBufferedPaintDC and wxAutoBufferedPaintDC.
The first one has no double buffering, the second has it’s own double buffering implementation (this can lead to using double double buffering - sorry for the play on words - on some platforms) and the last one uses its own double buffering on platforms that do not support it or the platform specific implementation otherwise. There are, of course, other ways to deal with double buffering, like call wxWindow::IsDoubleBuffered to determine whether you need to use buffering or not. Sorry, but I feel this really sucks
Number two.
The API names are all but intuitive and correlated API calls have inconsistent names or parameter types.
An example from the wxFileDialog class:

wxString GetFilename() const

Returns the default filename.

wxFileDialog::GetFilenames

void GetFilenames(wxArrayString& filenames) const

Fills the array filenames with the names of the files chosen. This function should only be used with the dialogs which have wxMULTIPLE style, use GetFilename for the others.

Note that under Windows, if the user selects shortcuts, the filenames include paths, since the application cannot determine the full path of each referenced file by appending the directory containing the shortcuts to the filename.

wxFileDialog::GetPath

wxString GetPath() const

Returns the full path (directory and filename) of the selected file.

wxFileDialog::GetPaths

void GetPaths(wxArrayString& paths) const

Fills the array paths with the full paths of the files chosen. This function should only be used with the dialogs which have wxMULTIPLE style, use GetPath for the others.

There are a few IMHO obvious problems in these APIs:

1. They are not intuitive. GetFilename returns the default filename? Why don’t you call the method GetDefaultFilename?
2. They are not consistent. GetFilename returns the default filename, the plural version GetFilenames returns the selected files. Two completely different methods with the same name.
3. Platform dependency problems and inconsistent behaviour. Look at the note about shorcuts on Windows. And what about Unix links? No mention.
4. Poor design. The GetFilenames and GetPaths methods should be valid even if the dialog does not have the wxMULTIPLE style.

Number three.
This point might be even more a personal opinion than the other ones, that’s why I’ll be very brief.
wxWidgets was started in 1992 and the first version 2 release (I don’t take the 1.x series into account) are roughly dated 1998. That’s about 8/9 years ago. Trying to read the wxWidgets source code I realized that the whole framework didn’t really evolve in these 8 or 9 years. That’s plenty of time. I think it’s time for a new major 3.x release. There’s too much legacy code in wxWidgets 2.x… way too much for me.

Number four.
Documentation. I will never stop complaining about bad or missing documentation. My previous post(s) on OpenSSL are an example Sorry but I am fully convinced that a good reference documentation can help developers do their work the best way and spending the least time.
And it can really help newbies to appreciate a tool or library.
The wxWidgets reference docs are not that bad. They are sure better that the GTK reference docs Anyway, the wx docs are pretty too similar to Sun’s Java documentation or to Microsoft’s MSDN… there is a single word I like to use to express my opinion on these two reference docs: “stupid”. No offence, but they spend more time explaining the obvious than explaining the things that really matter.
This is the only real issue with the wxWidgets docs. Fortunately there is a huge user community and the wxWidgets official website is a great starting point if someone needs to solve a problem.

That’s all folks.
No doubt wxWidgets is one of the best GUI frameworks I have seen so far, but the issues mentioned above are a good reason for me to avoid them