Some 3.0 release stats

So wxWidgets 3.0 is finally released. We should have done it much sooner than 7 years after 2.8.0 release, but better late than never. And at least this gives us a lot of statistics to analyse to see how much has changed since the last major release. So let's do just this.

Using git log shows that, in total, there have been 19224 commits (or 7.6 commits per day on average), changing 10352 files (3680 of which are new) with 2 085 638 insertions and 1 767 670 deletions, i.e. about 320 000 new lines. However these statistics are skewed by several big reorganizations that happened during 3.0 development: we moved wxPython out of the main wxWidgets repository, removed most of the old contrib directory and also converted the old documentation in LaTeX format to Doxygen. So maybe restricting ourselves to the code only, i.e. just include and src subdirectories is more fair. In this case, there are "only" 13857 commits changing 5132 files (and 600 files were added) with 926 608 insertions and 722 382 deletions i.e. more than 200 000 new lines of code. Which, by the way, brings the total number of lines of code in wxWidgets to more than 1.1 millions. To which should be added slightly more than 200 000 lines of documentation, more than 100 000 lines of the examples and, an area which has been especially greatly improved since 2.8, more than 50 000 lines of unit tests. Of course, the numbers of commits and lines of code don't mean everything and our numbers are not especially impressive anyhow, compared to other well-known open source projects such as Linux kernel or Apache, but, if nothing else, they show how active the project development was during all these years even in absence of any new stable releases.

Besides wxWidgets code base, a lot of other things have changed since 2007. One of them is that we're using Subversion instead of CVS now for version control. Naturally, a possible conclusion could be that things haven't changed enough as we still don't use Git for the official repository, even though I personally haven't used anything else since several years and we have an up-to-date Git mirror now. One of the problems of not using Git is that I don't have an accurate count of contributors to wxWidgets. While git shortlog does give the numbers of people who committed to svn, there are only about 25 of them, as almost all patches submitted to us ended up being committed by me and Subversion doesn't preserve the original authorship information. My personal estimation is that there must have been around 300 external contributors since 2.8 (we have about 220 of them mentioned in the change log but not everything is mentioned in it). Huge thanks to all the people who have kept helping improving wxWidgets and contributing back to community!

Looking forward, I have no idea when will 4.0 release happen nor what will it contain. But we'll definitely make 3.2 release sooner than in 7 years, even if it will probably mean less impressive numbers in its announcement post. In the meanwhile, enjoy using wxWidgets 3.0 — I know that we will enjoy having finally made it!

Second release candidate of 3.0.0 available

We have just made 3.0.0-rc2 files available. There are no truly exciting changes since 3.0.0-rc1 but this is the final release candidate before 3.0, so please test your applications with it and let us know if you find any real showstopper problems for the last chance of fixing them before 3.0.

You can get the release files, including binaries for not only MSVC but also MinGW-TDM this time, from SourceForge. More details are in the release announcement post and you can discuss this release on reddit.

wxWidgets and C++ 11

I've recently learnt† that the latest edition of Bjarne Stroustrup's "The C++ Programming Language", updated to cover C++11, mentions wxWidgets as one of the commonly used C++ libraries (you can search the book at Amazon for "wxWidgets" to find the relevant paragraph). Being mentioned in the bible of C++ is always nice, of course, but isn't it strange that a book about C++11 references a purely C++98 library? Of course, C++11 is almost fully backwards compatible with C++98 and wxWidgets can be compiled with a C++11 compiler (e.g. under Unix, just pass CXX="g++ -std=c++11" to configure) but this is not very interesting. More so is how the new C++11 features make writing code using wxWidgets simpler and this is the topic of this post.

To illustrate this, let's look at a very simple program written in C++ 98: It simply shows a window with a button and increases the button font when it is pressed. It's not especially useful but does show a few typical constructs appearing in real-life programs. This version can be compiled with just about any C++ compiler (VC6 need not apply) and works with any wxWidgets version since 2.9.0, which introduced Bind().

So let's now look at the version updated to use some C++ 11 features: This version requires a C++11 compiler, e.g. g++ 4.7 or later (tested with 4.8), MSVC11 (a.k.a. Microsoft Visual Studio 2012) or clang 3. It also doesn't quite compile with wxWidgets 2.9.5, so currently you need the latest Git/SVN sources. But it will compile out of the box with wxWidgets 3.0, of course.

The functionality is exactly the same, so what are the differences?

1. The most important change is undoubtedly the possibility to use lambdas as argument to Bind(). This is very useful for writing simple and short event handlers as it allows to keep the handler code together with the code creating (or loading from resources) the control. Notice that you need to capture this pointer by value in the lambda, hence the = in the line 12. Also notice that the lambda still must take (unused) wxCommandEvent&. This is something that we might get rid of in the future.
2. The possibility to use the new for loop is also quite appreciable, notice how much simpler iterating over the child windows has become.
3. Finally, there are small changes such as using nullptr instead of NULL, the added override in line 28 ensuring that you really override the base class method and using auto for the variables declaration. This is not really related to wxWidgets and I'm not completely convinced myself about the benefits of using auto everywhere (yet?) but if you are, perhaps after reading this article, you shouldn't encounter any problems doing it.

So, finally, even without any serious modifications to wxWidgets itself, the most user-visible changes of C++11 can be used in the programs using the library. Of course, there are many other C++11 features which would be very useful in the library implementation too and I'm very much looking forward to the variadic templates support becoming common enough to use them instead of the macro-based approach for the implementation of wxPrintf() and similar functions. But for now just using lambdas for the event handlers is already very nice.

---

† Thanks to Herb Thompson for noticing this.

Continuous Integration with Travis

Travis is a continuous integration system which works nicely with GitHub, so while we've been using Buildbot since a long time and will continue to do it, we thought it could be nice to also try Travis and so now we have a minimal configuration file for it and it builds wxGTK after each commit.

You can check the latest Travis build status by just looking at this blog post: and you can click the button for more details. For the other ports and also to check if the tests pass (as Travis currently only checks the compilation and doesn't run the tests yet), see our Buildbot status page.

Help with pre-2.9.5 testing

We plan to release 2.9.5 next Monday, so any testing right now would be even more welcome than usual -- as 2.9.5 is supposed to be the last release before 3.0, it would be great to avoid having to do any big changes after it is done and for this we need to avoid having the kind of bugs requiring such changes in the release in the first place.

So if you can grab the latest sources from SVN or Git and test them with your application, it would be really helpful. Especially if you discover any news bugs while doing it. And even more so if you don't ;-)

Thanks in advance!

---

P.S. Currently wxX11 and wxMotif are known to be broken (and will be fixed before 2.9.5) so testing these ports is not worth doing, but all the rest of the ports are supposed to work.

The fastest image format to load is...

... surprisingly, at least to me, TIFF. I have recently added a simple benchmark for wxImage methods, mostly to be able to test the optimizations to wxImage::Scale() done by @Hsilgos, but it also looked like a good opportunity to test the speed of loading the same image in different formats. And it turns out that loading the image from TIFF is consistently faster than loading it from JPEG, BMP or PNG even though the JPEG file is much smaller and I'd expect this to play a role. Actually, either the TIFF library under Linux is particularly optimized or the other ones are not optimized at all because using the system libraries for all formats (except BMP which is always loaded using our own code), loading TIFF image is more than twice faster than loading the JPEG one, 8 times faster and 10 times faster than loading the PNG one. Under Windows, where our builds of the libraries, compiled without any particular optimizations, are used, TIFF is relatively twice slower as it's only 10% faster than JPEG, 4 times faster than BMP and 5 times faster than PNG but the differences are still quite big.

The fact that using libpng turns out to be slower (albeit not by a large margin) than our own naive BMP loading code is rather surprising too but perhaps it's due to the code in wxPNGHandler which tries to determine the alpha format in a not very clever way. It would be interesting to profile this further and also test with other images (currently I have a huge sample of 1) and at least determine whether TIFF is consistently faster or just for some images (and, if so, for which ones) and whether this is specific to the code in wxWidgets or if the TIFF protocol or library is just really more efficient.

Simpler way to create fonts

Just a quick note about the new and simpler way to create fonts in wxWidgets 2.9: in addition to a multitude of wxFont constructors taking various font attributes, such as size, style, weight, face name and so on, there is now another constructor, taking a single wxFontInfo object that combines all of them together and allows to use the named parameter idiom for the font creation.

It may seem non-obvious how can adding another constructor help with the problem of having too many constructors, so here is a quick example to show how it does: suppose you want to create an underlined, 12 point version of "Courier" font. Here is how you'd do it currently:

wxFont f(12, wxFONTFAMILY_DEFAULT,
         wxFONTSTYLE_NORMAL, wxFONTWEIGHT_NORMAL, true, "Courier");

And here is how you'd do it with the new constructor:

wxFont f(wxFontInfo(12).Underlined().FaceName("Courier"));

Hopefully the advantages from the point of view of the library user are clear:

• You don't need to specify the default parameters such as wxFONTFAMILY_DEFAULT, that you don't care about.
• Each font attribute is clearly written out, while the meaning of true (which meant that the font should be underlined, by the way) was hardly obvious in the first form.
• You can specify the parameters in any order instead of having to check the documentation every time.
• Last and really least but still: you can create strike-through fonts (notice that they are only supported under MSW and GTK currently) using the new constructor using the natural Strikethrough() syntax, while this wasn't supported at all with the old constructor.

From our, i.e. developers, point of view, there is one extra important advantage, related to the last point: if support for a new wxFont attribute is added later, this way of creating fonts will be easy to extend to support it.

So my advice is to use wxFontInfo in all the new code using wxWidgets 2.9. The old constructors are not going anywhere and can still be used (except for the one taking int flags which was added for 2.9.4 and now removed to avoid ambiguities with the other existing constructors), but there is no reason to prefer them to the new one.

About the benefits of procrastination

And no, I'm not going to speak about why postponing 2.9.5 release for so long after its initially scheduled October 2012 release date is a good thing. Instead, I'd like to explain how can the recently added CallAfter() function make your life simpler.

CallAfter() is a method of wxEvtHandler, which means that it's available in the code of any classes deriving from it, including wxWindow but also wxApp and several others. And it basically allows to call another method of the class in which it is used asynchronously later. Notice that no threads are involved, the call to that other method still happens on the same main GUI thread but at a slightly later time. To be precise, the control first must return to the event loop and only then (i.e. "after") the specified method will be called.

Using it is quite simple: if you want to call some method Foo() taking 0, 1 or 2 arguments (this is the current maximum but it could be extended in the future if really needed), you can just write

void SomeWindow::OnSomeEvent(wxEvent& event) {
    // If the method doesn't take any arguments:
    CallAfter(&SomeWindow::Foo);

    // If the method takes an argument:
    CallAfter(&SomeWindow::Foo, arg1);

    // Or if it takes two:
    CallAfter(&SomeWindow::Foo, arg1, arg2);
}

Notice that Foo() must be a method of the same class. But other than that, this is pretty straightforward.

The above explains how to use CallAfter() but doesn't answer the really interesting question which is, of course, why would you ever want to do this instead of just calling Foo() directly? The answer is that some things often just can't be done immediately in a GUI program, either because doing them would interfere with its normal flow of control and generate extra events, potentially resulting in unexpectedly re-entering the same event handler and infinite recursion. Or because the current state of the program simply doesn't allow them. An example of the first case is showing a message box from a window activation event handler: doing this would immediately deactivate the window back again which is probably unexpected. An example of the second case is showing a message box from event handlers for all events generated by mouse click, e.g. button press event: as the mouse is captured by the button when the click happens, its mouse grab is released unexpectedly and the standard control itself can get confused by it, e.g. the button could appear to be stuck in pressed state.

The message box example is actually a poor one because wxWidgets already provides an easy way to prevent such problems from happening by using wxLogMessage() function which already postpones showing the message box until the next event loop iteration. What CallAfter() does is to provide you with a generic way to do the same thing very simply.

As a more realistic example, let's consider a common GUI layout with a tree control on the left and some window displaying the items in the tree on the right. Suppose you'd like to update the display when a tree item is double-clicked. There is a wxEVT_COMMAND_TREE_ITEM_ACTIVATED event corresponding to this action so typically you'd do something like this:

TreeViewFrame::TreeViewFrame() {
    wxTreeCtrl* tree = new wxTreeCtrl(this, ...);
    tree->Bind(wxEVT_COMMAND_TREE_ITEM_ACTIVATED, &TreeViewFrame::OnActivated, this);

    // This is the window showing the current item.
    m_view = new ViewWindow(this);

    DisplayItem(initial);
}

void TreeViewFrame::OnActivated(wxTreeEvent& event) {
    ... retrieve the item to show from the event (typically using client data) ...
    DisplayItem(item);
}

void TreeViewFrame::DisplayItem(ItemType item) {
    m_view->ShowItem(item);
    // Give the focus to the view to allow the user to easily use the keyboard.
    m_view->SetFocus();
}

And this works perfectly well except that the view doesn't get the focus after double clicking an item in the tree under Windows. The reason for this is that the native tree control there sends the activation event first and then processes the (second) mouse click which resulted in it itself, and as part of this processing it sets the focus to the control itself (as it's normal for the control to become focused when clicked). So while the view does get focus during the activation event handler execution, it loses it almost immediately afterwards.

In a perfect world, wxWidgets would somehow isolate you from this peculiarity of Windows tree control implementation. But doing this is rather not trivial and, remember, this is just one of several examples. So in the imperfect world we live in, you need to deal with this problem at your application level. CallAfter() reduces the imperfectness of having to do it to acceptably low level as all you need to change in the snippet above to make it work is to replace the last line of the event handler with the call to it:

void TreeViewFrame::OnActivated(wxTreeEvent& event) {
    ... retrieve the item to show from the event (typically using client data) ...
    CallAfter(&TreeViewFrame::DisplayItem, item);
}

All we did was to delay the item display until the next event loop iteration after the one which dispatched the activated event itself and this is enough to get rid of the focus problem.

So if you have any capture, focus or other global state problems (and notice that they can stem from your own code as well, and not just behaviour of the native controls or wxWidgets itself), you can often use CallAfter() to easily solve them by just postponing whatever you need to do until slightly later. Remember that laziness is a cardinal virtue for a programmer -- and now wxWidgets helps you to cultivate it!

---

P.S. But we'll still try to release 2.9.5 soon...