Thursday, February 04, 2016

What g++ binaries for 3.1.0 release?

We plan to provide g++ binaries for the upcoming release, but we're not sure what are the versions and the build options that people would be interested in, so here is a quick poll to gather some information about this:

polls

Please select 1-3 options corresponding to the binaries that would be useful to you to allow us to make the best choice. Thanks in advance!

Monday, February 01, 2016

3.1.0 Is Coming

Although we've been talking about it since quite some time, this time we're really going to make a new release soon. To be even more precise, I firmly expect to make it this month. Of course, I did wait until January was over to announce it. On the other hand, I did not wait for the February to be over neither even though it's the shortest month of the year. On still another hand, we did wait an extra year for this release, presumably just to have one extra day to make it in February of this year, as opposed to the last one... In any case, barring something really catastrophic happening, we should have a pre-release on February 15 and the release some time after that.

Of course, deciding to make the release is not quite enough, there are other things to do too, such as applying at least the most urgent and long standing patches and fixing selected bugs. So this week-end I spent some time doing this and, as the result, instead of 49 3.1.0-critical bugs we now have only 20 of them which is not as good as I hoped, but better than I expected. Of course, some of these bugs were just postponed, while others turned out to be not bugs at all after all or to have been already fixed. Still, quite a few real bugs and, notably, a few regressions which really couldn't remain before the release, were fixed as well, so there is that. I hope to deal with the remaining bugs during the next week and maybe even apply some non 3.1.0-targetted patches too, but in the worst case we could just postpone all the remaining 3.1.0 tickets as there is nothing absolutely critical there (and only a couple I'd characterise as being moderately critical).

So things look cautiously good for 3.1.0 and if we make it according to the plan, thus proving that our new release scripts, updated after the switch to git, work, hopefully 3.0.3 will follow soon afterwards.

Thursday, January 21, 2016

Dropping Carbon support under OS X

We would like to remove the old Mac OS X port using Carbon in the upcoming 3.1.0 release because we think nobody should be using it any longer (and we definitely know that nobody building 64 bit applications does because Carbon just doesn't exist in 64 bits) and it would make things simpler for us. But "should" and "is" are different things and if there are more than a handful of people who are still using Carbon and can't migrate to wxOSX/Cocoa port (I'd like to know why!), but, at the same time, still plan to update to 3.2 in the observable future, we could reconsider this. So if you'd like Carbon to continue to be supported, please let us know, in the comments here or on the mailing list. Thanks!

Sunday, June 14, 2015

Build fixes for different gcc distributions under Windows

I've spent most of the day today fixing various compilation issues for the three most often used distributions of gcc under Windows: TDM-GCC, mingw-w64 and the "classic" MinGW trying to ensure that the upcoming 3.0.3 release (as well as the current master) builds out of the box with all of them using all the common build scenarios. TDM-GCC and mingw-w64 required just one minor fix for g++ 4.9.2 which started providing clang-like __has_include() except with different (and IMHO completely useless) semantics, so we just have to ensure that we don't use it with gcc even if it is available which was easy to do and actually had been already done on master.

However things were much more interesting with MinGW. The main problem with it was that it couldn't be used to build wxWidgets with -std=c++11 option (nor -std=c++98 one, but almost nobody ever used this one anyhow) nor, even worse, even use this option when compiling applications using wxWidgets as it broke compilation of wxWidgets headers. There always was a simple workaround of using -std=gnu++11 option instead, but it only was simple once you knew about it, which wasn't the case for most of first-time wxWidgets users who ran into it. So I finally decided to make -std=c++11 work as well and now it does, even though this wasn't simple nor pretty.

The summary is that now building with all 3 compilers with and without -std=c++11 works. And, as a side effect of this, I also fixed some (mostly harmless) warnings so that building with MinGW and mingw-w64 now doesn't give any -- at least in the configurations I tested. TDM-GCC is pickier (which is probably a good thing) and still gives quite a few warnings, so using -Wno-unused-value in CXXFLAGS with it is recommended: with this option only a couple of warnings in 3rd party code remain.

Of course, there are too many combinations for me to have tested all of them: 2 branches (3.0 and master), C++11 and C++98, static and shared, Unicode and ANSI, STL and not-STL already give 96 builds to test and there are other options too. So, before I spend too much time congratulating myself, it would be great if people could actually test the build configurations they use and are interested in and report if there are any (and especially any new) problems with them as I'm sure I must have also broken something with so many changes. I'm just not sure what, yet -- please let me know!

Tuesday, April 07, 2015

Validating XRC

Overview

If you write your XRC files
by hand (which is probably relatively rare as most people prefer to edit them visually, but it does happen), and if you are human (which is probably not so rare), you are bound to make mistakes in them. Some of these mistakes result in invalid XML which give errors when loading the XRC file, some of them are not a big deal and are just ignored by the XRC parser, but some others can result in the layout mysteriously not working as expected, which can be annoying. Validating XRC files, i.e. verifying that they conform to the scheme describing all the valid XRC elements, allows to avoid all these problems at once, so it is strongly recommended to do it -- and this post will explain how, in details.

Setup

To validate them you need two things: a schema and a tool using it. The schema exists in our repository since October 2013 and is also available at the public URL http://www.wxwidgets.org/wxxrc. As for the tools, anything supporting compact RELAX NG schema syntax can work, but in practice this seems to limit the choices either to the online validator at validator.nu (Edit: this validator can't be used for validating XRC currently as RELAX NG support seems to be broken) or the original command-line validator, written by James Clark, one of the persons behind RELAX NG, called Jing, and the offline version is, unsurprisingly, much more useful as it can be integrated into the build process or used as part of pre-commit hook checks easily, so this is the one we are going to look at.
The latest Jing release is available from Google Code, but as the entire site will be closing soon, it might not work any longer by the time you are reading this, so here is the smaller and more up-to-date version. It is completely standalone and requires just a working Java installation, you can put the JAR file anywhere you want and simply run
$ java -jar /full/path/to/jing/jar
(in spite of the dollar sign indicating the Unix prompt, this works under Windows, too). The basic Jing command line syntax is just the schema file followed by any number of files to validate, however XRC schema uses the compact syntax which has to be explicitly selected by its -c option, so in the simplest case the full command line would look like
$ java -jar jing.jar -c $WXWIN/misc/schema/xrc_schema.rnc myfile.xrc
where WXWIN environment variable is supposed to contain the full path of your wxWidgets installation.
As an aside, it is also possible to avoid hard coding the path to the XRC schema, which may be important to make the validation step work on different machines. The natural way to do it would be to just use the canonical URI instead of the path to the schema, i.e. http://www.wxwidgets.org/wxxrc but currently this doesn't work, seemingly because of a bug in Jing handling HTTP-to-HTTPS redirections. The following command does work:
$ java -jar jing.jar -c https://www.wxwidgets.org/wxxrc myfile.xrc
but still has two problems: first, the URI is, formally speaking, wrong as it should be using "http" schema. Second, and probably more importantly in practice, it can be slow as the file needs to be downloaded from network every time. To fix this problem, an XML catalog mapping the canonical URI to a local file can be used. I won't pretend to know much about XML catalogs (because I don't), but here is a minimal one that can be used to set up the correct redirection:
If you save the above file as catalog.xml and adjust the value of the uri attribute to contain the correct path to xrc_schema.rnc on your machine (notice that triple slashes are needed), you should be able to use
$ java -jar jing.jar -C catalog.xml -c http://www.wxwidgets.org/wxxrc myfile.xrc

Using (or not) Custom XRC Elements

After the setup describe above you can use the standard schema xrc_schema.rnc to validate the contents of all the standard XRC elements, such as <sizeritem> or <object class="wxButton">. However any custom elements are simply ignored by default because the standard schema has no knowledge of them. Of course, you might not have any custom XRC elements at all. In this case, you should use xrc_schema_builtin_only.rnc, located in the same $WXWIN/misc/schema directory of your wxWidgets installation, to forbid any of them from appearing. There is no canonical URI for it, so you should simply pass full path to it on Jing command line.
The more interesting case is when you do define some custom XRC handlers. In this case using xrc_schema_builtin_only.rnc would result in errors about invalid value of attribute "class" for all your custom elements, so you need to define a custom schema describing just them. An example of doing it is shown in misc/schema/README, but here is an even simpler custom schema:
This schema allows appearance of a custom Frobnicator window-like (because of stdWindowProperties inclusion) element which can have one specific (but optional, because of the trailing *) num_times attribute, i.e. would validate the following XRC fragment: if you issue
$ java -jar jing.jar -C catalog.xml -c frob.rnc frob.xrc
command. Of course, the same fragment would also be accepted by the standard schema, the real benefit of using a custom one is that typos in either "Frobnicator" or "num_times" would be detected only by the latter.

TL;DR Summary

Your easy guide to XRC validation:
  1. Download jing.jar
  2. For one-time validation of only standard XRC elements just run
    $ java -jar jing.jar -c https://www.wxwidgets.org/wxxrc myfile.xrc
  3. For repeated use, download XML catalog, edit the file path in it and run
    $ java -jar jing.jar -C catalog.xml -c http://www.wxwidgets.org/wxxrc myfile.xrc
  4. If you use custom XRC elements, consider defining a schema for them too, it is simple to do.

Thursday, March 12, 2015

Attributing the contributions

One of the lesser, but still appreciable, benefits of switching to Git is that now we can properly record the author of the commit (e.g. the author of a patch), in addition to the (less important) person who committed it (e.g. me). While we tried to do this manually in the change log before, this couldn't be done for all the changes as the change log only mentions the most important ones and, sometimes, could be forgotten even for those changes for which it should have been done.

With Git, things are much more straightforward and you just need to provide your identity with your patch. The simplest way to do it is to use git format-patch command -- after ensuring that your name and email are correctly configured locally, of course. But you could also just mention them in your Trac ticket or wx-dev email and we'll use them when committing your changes (note for committers: you can always set GIT_AUTHOR_{NAME,EMAIL} for a particular commit to set the authorship information by hand).

Looking forward to your patches -- which will be now properly attributed to you instead of boosting my own commit stats!

Wednesday, December 31, 2014

A year in wx

2014 hasn't been the most exciting year for wxWidgets -- among the recent years this honour certainly belongs to 2013, which finally saw the release of the long, long awaited 3.0 release. However quite a few things still happened during it.

First of all, thanks to Bryan Petty, we now have a new shiny web site which not only looks much better, but is also simpler to update and to contribute to.  And it was duly updated more often, in particular to announce two new releases (3.0.1 and 3.0.2) last year, which is two more than we typically make per year.

Second, after a two year hiatus, wxWidgets was part of Google Summer of Code again this year and we had 6 students working on several interesting projects, admittedly with various degrees of success. But work done by Alexandru Pana on Direct2D support, by Chaobin Zhang on new Windows Vista/7 taskbar features, Sun Boxiang on wxUniv/X11 and Mariano Reingart on wxQt port was already merged into the trunk and we hope to merge Haojian Wu's work on Chromium backend for wxWebView before the next release.

Third, in 2014 we welcomed a new member to wxTeam: Artur Wieczorek has started by submitting many important improvements to wxMSW and then also volunteered to become the maintainer of wxPropertyGrid control and has since improved it as well. Thank you Artur!

Other than that, life continued as normal in 2014 with 1678 commits in master and 375 bugs fixed (compared to 1471 and 332 in the previous year).

What are we looking towards in 2015? Definitely a 3.1.0 release and almost certainly a 3.0.3 one. With luck, 3.1.0 will include a new and reworked AUI version. On infrastructure level, after upgrading the web site, the next long-awaited change is officially migrating to git from svn. Finally, we hope for as many contributions from the community in the next year as in the last one, thanks to all (too numerous to list here, sorry!) who submitted patches or sent us bug reports and please continue to do it!

Thank you and happy New Year!