Tuesday, April 01, 2014

Announcing the Great Rewrite

It has become increasingly clear during the last few years that the current wxWidgets code base is simply too out of date for the present day connected, mobile, cloud-based computing world. So, after a deep and careful consideration, we have decided to launch a new project, wxWidgets 2020, which will allow us to remedy this.

The major change to be done in the framework of this project is to switch the implementation language of the library. Clearly, nothing worthwhile can be written nowadays in anything other than JavaScript. While we unfortunately wasted our chance to port wxWidgets to Java in the nineties and thus completely missed the Java desktop revolution, we still can correct this by using JavaScript which, as a language, combines the unparalleled elegance and efficiency of Java with great scripting support (as obviously follows from its name). JavaScript is clearly the language of the future as in addition to the its brilliant success on the client side, it is now even displacing the pinnacle of software engineering which is PHP on the server side, thanks to amazing innovations such as reimplementation of the best features of Windows 3.1 in node.js. Moreover, by using JavaScript we will finally be able to increase the visibility of wxWidgets by hopefully appearing more often in security advisories, which was difficult for us so far due to the total lack of support for XSS and CSRF in C++.

Of course, we, wxWidgets developers, take the backwards compatibility seriously and so we have also thought of a couple of the current users of the library who might have some existing C++ code. Luckily, migrating it to wxWidgets 2020 should be easy to do as you'd simply need to recompile it using asm.js which will be proven to work flawlessly as soon as we test it. And if it ever doesn't, there is always the fall back solution of continuing to run the existing code unchanged inside a virtual machine running inside the web browser -- after all, the modern hardware is largely fast enough to allow doing this, and it would be a pity to keep these CPUs idle.

Finally, the most difficult aspect of this decision was, as usual, choosing the name. After a long and agonizing discussions, we agreed on 2020 which gives us a reasonable amount of time before the release (while releasing wxWidgets 3.0 did take more than 6 years, we are confident that things will happen much faster now that we have the magic of JavaScript at our disposal). And if we miss that deadline, we can always pretend that the name was just a play on "Web 2.0" (only twice as much). As you can see, we have thought of everything. Watch this space!

Monday, January 27, 2014

Looking for project ideas for GSoC 2014

Google Summer of Code 2014 will start accepting applications soon and we plan to submit one for wxWidgets, as we have done every year since 2006. Unfortunately, last year our application wasn't accepted and while technical issues with our GSoC 2013 web site were given as the main reason for its rejection, I think lack of really good project ideas played its role as well. So we'd like to do better this time and try to propose more and, most importantly, more interesting projects to the students.

Coming with the good project ideas is not that simple however, so I'd like to ask for your help, hoping that perhaps it's easier to come up with something new, interesting and original from the outside perspective. So if you think you know some fun to work on, yet useful project that we could propose to the students this year, please let us know -- either in the comments here, or by posting to one of our mailing lists. Let me just remind you that GSoC projects must be about programming and should be realistic, i.e. the task should be such that we could reasonably expect a student to complete it in 3 months of work. And, once again, ideally it should be something students would be motivated to work on.

Looking forward to your ideas!

Monday, November 11, 2013

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!

Monday, October 28, 2013

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.

Thursday, August 29, 2013

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.

Friday, July 26, 2013

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.

Tuesday, July 09, 2013

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.