Sunday, June 17, 2018

wxBlog Moved to wxWidgets Website

I'd like to encourage readers of this blog to update your bookmarks and RSS subscriptions to use the new home of the official wxWidgets developer blog:


For a while now, our official wxWidgets news feed has been managed through our "website" git repository on GitHub. This allows anyone to contribute news posts (whether you consider yourself a major contributor to wxWidgets, or just want to publish a guest post) through a typical pull request on GitHub, and we want to encourage developers in the community the same freedom to contribute new posts on our developer blog as well. If you would like to contribute a new blog post, please check out the new website guide.

We have imported in all existing blog posts to the new location, however, we are unable to import existing comments from the wxBlog. We still plan to keep this old blog up for the foreseeable future though. We hope you enjoy the new home of the blog.

Thursday, March 08, 2018

3.0.4 Released

We have finally, after a long delay, released 3.0.4, please see the announcement or go directly to the release page. As with the previous 3.0.x releases, there are no important new features in this release, but there are quite a few bug fixes as well as support for the relatively recent compiler, platforms and third-party libraries versions which were not yet (widely) available at the time of 3.0.3, so upgrading to it is strongly recommended for all 3.0 users, especially because it is so simple: the new release is 100% compatible with 3.0.3 and doesn't require any changes to your applications code or, if you are using shared libraries, not even recompiling it.

As always, thanks to everyone who has contributed to this release and helped with preparing it, by building the binaries, documentation and testing it!

Monday, February 19, 2018

wxWidgets 3.1.1 released

After fixing a few more bugs since the release candidate, we've just released the final version of wxWidgets 3.1.1. I won't repeat the announcement email or the release announcement on the web site, but would just like to say a few words about the focus of this release and the future plans.

First of all, even though there are quite a few new features in 3.1.1, most of the changes in this release are bug fixes and improvements. wxWidgets is still by no way bugs free, but a lot of long-standing problems were fixes, especially in GTK+ 3 and macOS ports, as well as wxDataViewCtrl bugs (although, again, not all of them, by a long shot). This is, of course, hardly as exciting as shiny new features, but is arguably at least as useful. It's also in line with our goal to release the new stable 3.2.0 relatively soon.

We do hope to have at least one important new feature in the next release: support for per-monitor DPI, with all that this entails, i.e. taking care of as much as possible in the library itself and letting the application handle the rest. My -- probably, as usual, too ambitious -- personal plan is to implement this soon and release 3.1.2 in June, and then 3.2.0 in the autumn. Of course, release planning is mostly made to be broken, at least in our case, but one of the changes in this release is that it's now much simpler to make new releases and the process is much more streamlined, so maybe this plan is not as unrealistic as it might seem.

In the meanwhile, I'd still like to repeat one thing from the release announcement: please consider updating to 3.1.1 a.s.a.p. There are almost no incompatible changes in this release since 3.1.0 and only a few compared to 3.0, so it shouldn't take much time (or, sometimes, any time at all) to upgrade and you do get all the bug fixes mentioned above, which are very worth the upgrade, even if you don't plan to use any new features immediately.

Monday, February 05, 2018

Release candidate for wxWidgets 3.1.1 available

The release candidate for the next wxWidgets release is available here and any help with testing it would be appreciated. Please consider rebuilding your applications using it, it shouldn't be difficult if you're already using wx 3.0 or later, as this release has few backwards incompatible changes compared to 3.0 and practically none compared to 3.1.0, and if you encounter any problems with either building or running them with the new release, please let us know so that we could still have a chance to fix them before the final 3.1.1 planned in two weeks time.

Here is a more detailed description of the new release if you'd just like to see what is new in it (but there will probably be another post about it here after 3.1.1 itself).

Thanks in advance!

Saturday, December 02, 2017

GSoC 2017 summary

As previously mentioned, wxWidgets has participated in Google Summer of Code again in 2017, after a 2 year hiatus. We had only 2 projects this time, but the good news is that both of them were successful and, as of 15 minutes ago, been merged into Git master and will be available in the upcoming 3.1.1 release.

The first project, by Jose Lorenzo, enhanced wxWebView::RunScript() to allow returning values from JavaScript code executed by this function back to C++. This wasn't a particularly big change, but it is an important one as it makes it possible to write mixed C++/JavaScript applications using wxWidgets for the standard UI parts and wxWebView for richer or more dynamic parts.

The second project, by Prashant Kumar, had a much greater scope and added support for handling gesture events, such as pinch-zoom or double-finger-rotate. This required adding new API covering the quite different native APIs provided by MSW, GTK+ and macOS and implementing it for all these platforms, congratulations to Prashant for getting it all done! The only snag is that we don't really have any multi-touch-capable devices to test this work with, so it's possible that the new code still has some issues -- but, in the best open source tradition, we count on our uses to let us know about them.

Finally, while it doesn't affect wxWidgets users directly, GSoC is also nice because it provides a rare opportunity for different wxWidgets developers to meet together at the mentor summit after its end. And this year this allowed me to finally see Mariano Reingart, who was himself a GSoC student a few years ago and was a mentor this year, in person for the first time ever:


Thanks again to our students and, of course, huge thanks to our mentors: Cătălin Răceanu, Mariano Reingart and Steven Lamerton, as well as to Bryan Petty who took care of all the organisational chores. Finally, we are obviously very grateful to Google itself and the GSoC team there, for making all this possible. We hope to be able to take part in GSoC 2018, which will already start soon, so please help us by spreading the word about this programme among any students you know and let us know if you have any interesting ideas for the student projects.

Sunday, November 12, 2017

Surreptitious Submodule Switch

During the last couple of days, we've transitioned all the third party libraries used by wxWidgets, such as libpng, libjpeg and so on, to use Git submodules instead of just subdirectories in the main repository. If you don't use Git to get the latest and greatestfor the appropriate definition of "great" wxWidgets, you don't need need to read further as it shouldn't affect you in any way except for resulting in faster and more frequent updates to these libraries (but still consider starting to use sources from Git to help us with testing!).

If you do use Git, you will notice that your next update, i.e. git pull or git fetch && git merge --ff-only origin/master, will delete all files in src/{expat, jpeg, png, tiff, zlib} directories. Do not be alarmed by this but do run

git submodule update --init
to initialize and get the latest contents of all the submodules. This will, unfortunately, take quite some time, and if you use a not too ancient version of Git (2.8 or later), you should be able to speed the process up significantly by doing
git fetch --recurse-submodules -j2
instead, where "2" could be replaced by any number up to 5 (higher would be useless with only 5 submodules).

During subsequent updates, if you notice any change to one of the submodules, you need to only rerun git submodule update (without the --init option) and it will be much faster. Other than that, your use of wxWidgets Git repository shouldn't have to change in any way, the only difference is now most of Git commands won't recurse into submodules, at least by default, so git grep, for example, won't find any matches in the subdirectories mentioned above by default. However mostly the new behaviour is more useful, and you can use the same --recurse-submodules option with a few Git commands to change it if really needed.

Of course, if you do find any problems due to the switch to submodules or third party libraries upgrades that have taken place together with it (we now use the latest versions of all of them, notably jumping from libjpeg 6b released in 1998 to 9b, released in 2016), please let us know on the mailing lists, as usual.

Sunday, May 28, 2017

Configure is now less forgiving

Just a word of warning: it was previously possibly to write ../configure --enable-bloordyblop and configure would happily run and just ignore the unknown option. This could be seen as being nicely lenient but, in fact, was much more often aggravating as it allowed typos in configure options to slip through, resulting in many "WTF are my library binaries still not optimised even though I did use --enable-optimize?". The answer is, of course, as previously mentioned, wxWidgets British roots: you were supposed to use --enable-optimise instead. But while sticking to the right spelling might be commendable, not giving any errors for the wrongalternative one is definitely not. Moreover, this was never intentional and happened only as an unfortunate side effect of how Autoconf AC_CONFIG_SUBDIRS()macro worked

And this has finally changed: since this recent commit, which will be part of upcoming 3.1.1 release, unrecognised configure options will result in an immediate error. And while the new behaviour is better, it does risk breaking a few of the existing build scripts, e.g. if you use obsolete options (such as --enable-compat24) or, indeed, if you made a typo in one of them. In this case, please just remove the options that don't exist any more (they were previously ignored anyhow) or fix the typos. And in the unlikely case when you really need to pass an unsupported option to wx configure script (why would you do this?), you can always explicitly use --disable-option-checking on the command line to continue doing so -- and you will even get an error if you make a typo in this one!