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!

Friday, May 05, 2017

Our GSoC 2017 students and projects

After an average of one post every 6 months or so on this blog, good news just can't stop coming now, with a second post in just 3 days. This one is to announce that wxWidgets has been allocated two slots in this year Google Summer of Code program and Prashant Kumar and Jose Lorenzo will be working on adding support for multi-touch gestures and providing better integration with JavaScript in wxWebView this summer.

Congratulations to Prashant and Jose and thanks to everybody else who applied (but, unfortunately, couldn't be accepted) to work on wxWidgets and also to our mentors: Cătălin Răceanu, Mariano Reingart and Steven Lamerton. And good luck to all involved!

Tuesday, May 02, 2017

3.0.3 Released

We have finally, after a long delay, released 3.0.3, 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.2, 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.2 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 (at least 66 people according to git commit information, but certainly more in practice) and helped with preparing it, by building the binaries, documentation and testing it!

Monday, March 27, 2017

Last call for proposals for GSoC 2017

This is just a reminder that wxWidgets is one of the mentoring organizations in this year Google Summer of Code program and we are looking for proposals from motivated students with knowledge of C++ and interest for cross-platform development.

There is less than a week remaining before the deadline for submitting GSoC applications, so, if you are a student, or know of a student, interested in participating, please hurry up!

Sunday, February 19, 2017

Safer S...

I want, of course, to talk about "Safer Strings" today.


TL;DR: Add /DwxNO_UNSAFE_WXSTRING_CONV=1 to your compiler options today.


wxWidgets has had implicit conversion of wxString to const char* since the dawn of time (or about 1992, at any rate). This was always dangerous, as it allowed someone to accidentally write:

void show_and_free(const char* p) { ...; free(p); }
wxString s("...");
show_and_free(s);
with catastrophic consequences, but such situations were relatively rare and it was thought that the convenience of having this implicit conversion overweighted the dangers. This is also why when we added Unicode support later, we also added implicit conversion to const wchar_t* and, when we added "STL" build mode, in which interoperability with the standard library is increased further even at the price of backwards compatibility, we added implicit conversions to std::string and std::wstring as well.

Unfortunately, with the merge of ANSI and Unicode build modes in wxWidgets 3, another, much more dangerous, problem has appeared because in the new combined mode we can now have a string containing Unicode characters not representable in the current locale encoding. And converting such strings to either char* or std::string inevitably results in a loss of data in this case, e.g.

double convert_temperature_to_celsius(const char* p) {
    const char* end;
    double t = strtod(p, &end);
    return 5.*(t - 32)/9.;
}

wxString s = wxGetTextFromUser("Enter temperature");
convert_temperature_to_celsius(s);
could, confusingly, result in always returning -17.77777, corresponding to 0°F, if the user decided to terminate the temperature entry with "°F" to explicitly indicate the scale used and the current encoding couldn't represent the degree symbol (which is the case of e.g. CP1250 under Microsoft Windows). In this case, conversion of wxString to char* would fail and p would be just empty.

Of course, this wouldn't happen if the code just used wxString::ToDouble() directly, or used wxChar and wxStrtod(), or used UTF-8, capable of representing any Unicode character, as encoding (which is practically always the case under Unix systems nowadays). So there are a lot of ways to write this code correctly, but, unfortunately, it was still too simple to write it wrongly accidentally lose the data entered by the user in this case. Clearly, implicit conversions potentially losing data are a bad idea, but we couldn't just turn them off in wxWidgets 3, as it would have broken almost all the existing programs which, empirically, all used these conversions in many places.

For the same reason, we still won't be able to turn this conversion off by default, even in wxWidgets 3.2. However now we at least provide a way to opt-in into safer behaviour. The arguably less interesting part of the changes is that you can now change the value of the compile-time wxUSE_UNSAFE_WXSTRING_CONV option when building the library. It is set to 1 by default, for compatibility, but if you build wxWidgets for the use in your own project, you are strongly advised to set it to 0 to permanently disable the unsafe, in the sense described above, implicit conversions.

Many people, however, don't build their own library, but use the one provided by their package manager under Unix/macOS or download our MSW binaries. These official binaries will continue to provide the unsafe conversions for compatibility, but you can define wxNO_UNSAFE_WXSTRING_CONV when building your own project to disable their use in your code without rebuilding the library. This symbol can be just #define'd before including any wxWidgets headers, but it is better to define it globally, in the compiler options in your make- or project file: just add /DwxNO_UNSAFE_WXSTRING_CONV=1 to it. And the main point of this long post is to convince you that you NEED TO DO just that: please define wxNO_UNSAFE_WXSTRING_CONV for your code and fix the resulting compilation errors to ensure that you don't lose any data entered by the user.

Fixing the compilation errors will, generally speaking, involve doing one of two things:

  • Either stop using char* (or std::string in the STL build) entirely and use wxString directly.
  • Or convert it to wchar_t* (or std::wstring) or convert wxString to UTF-8 encoding which will never lose data, using methods such as utf8_str(), which is a convenient synonym for mb_str(wxConvUTF8), or ToStdString(wxConvUTF8).
Of course, if you really need to use the current locale encoding, e.g. because you call a C standard library function using it, you will still need to perform the conversion to it, using just plain mb_str() and there will still be a possibility of the conversion to it failing, but at least now it won't happen implicitly.

Thanks for reading all this and, if you jumped to the end, hoping to quickly find the conclusion instead of reading this wall of text, please see the conclusion in the very beginning!

Monday, June 13, 2016

How to Keep a Secret

If your program needs to ask the user for a password, e.g. to connect to a web site or a database, chances are that it proposes a way to remember this password and not have to enter it the next time. This is convenient for the users, but is quite difficult to implement in any more or less secure way and a lot of programs end up storing the passwords in plain text, or something almost indistinguishable from it, e.g. base64-encoded string, in wxConfig.

But now wxWidgets provides a better way to do it with the new wxSecretStore class. It is still as simple to use as wxConfig but uses the OS-provided password storage facility such as Microsoft Windows credentials vault or OS X keychain, for storing the secrets you confide to it. Here is how you would normally use it:

Currently there is not much more that can be done with this class, the only functionality not illustrated by this example is deleting a previously stored secret, but in the future we could extend it, notably to provide a way to also ask the user to enter the password using the OS-provided dialog. Let us know if you use wxSecretStore and if you see possible improvements, please don't keep them secret!

Friday, April 01, 2016

Improving Inherently Important Internationalisation Issues

One of the lesser-known advantages of wxWidgets compared to many other libraries is that, using its API, you can centre a window on the screen and set its colour to grey without having to Americanise your programme. But, as natural as this behaviour is, and in spite of agreeing to wxWidgets licence (the very spelling of which should have been a sufficient hint), some users still expressed their surprise in their dialogue with us and refused our advice to accept using this flavour of the API. And so, to accommodate them, wxWidgets has traditionally provided alternatives such as Center() method, wxColor class and wxGRAY constant.

Admittedly, in practice this has been sufficient to avoid any problems for a long time while still remaining true to wxWidgets historically British roots. However, in addition to being British, wxWidgets was always mostly a European effort and, besides, knowing that it was actually born in Edinburgh, it might well end being exclusively European and not British at all in the near future (but don't worry, even if the worst happens, we plan to continue supporting British spelling for at least two more release cycles, in accordance with the general backwards compatibility policy). Considering this, it seems especially strange to have alternative American versions of the spelling, but no attention being paid to the other European languages.

And now, after releasing 3.1.0, it's finally time to do something about it as, clearly, there are few unresolved issues of comparable importance left. To begin with, I obviously had to add wxCouleur class which should undoubtedly help with wxWidgets adoption in francophone countries. But adding just the French variant would certainly be undiplomatic, so another pull request adds, in the grand European tradition of Franco-German alliance, wxFarbe, and both of them will be merged together to avoid any questions of precedence. Further, France and Germany notwithstanding, I certainly don't plan to discriminate against other countries but, in the usual spirit of Open Source, additions of wxColore, wxFarve, wxKleur etc will have to wait until the appropriate patches are submitted (luckily for them, Spanish users can, in the meanwhile, already reuse the American variant, just as they already do with many other words, e.g. burrito, for the classic American food).

Of course, nothing is ever as simple as planned and, while working on this, I quickly realized that Greek might present some practical difficulties as UTF-8 support is still, even in 2016, not perfect on some of the legacy platforms supported by wxWidgets, but it would be difficult to use wxΧρώμα without it. A compromise solution that we're currently discussing would be to introduce a wxChroma class right now and deprecate it by the time 3.2 is released as Unicode support should really be widely available everywhere by then (3.2 release is currently planned for the early 2030-ies).

I do hope you will enjoy these changes, but, let's be honest, this is just the beginning and we clearly still have a lot of work to do in this area. Fully supporting colour internationalization is important, but it's just the first step and we plan to go much further. Just imagine to be able to open a wxFenêtre and choose a wxStylo for drawing on it and then, perhaps if you live in Switzerland, create a wxKnopf as its child. The possibilities are endless! Unfortunately, the same can't be said about our resources, so we count on your help to make wxWidgets the best internationalized library of all time -- and we're looking forward to your contributions!

Monday, February 29, 2016

An unexpectedly expected release: 3.1.0 is available

Surprisingly, at least to me, we managed to make 3.1.0 release exactly as planned, i.e. today, without any delays. The price for this is that there are a couple of known problems in this release (see the errata on the release page), but we decided that it was not worth delaying the release for them.

This is not the most exciting release in wxWidgets project history, but it's still very much worth upgrading to as there has been a huge number of bug fixes in it, especially in wxGTK3 and wxOSX ports. Of course, as usual, there are a few new features as well, see the web site for a brief list and the change log for a fuller one and I'll try to find some time to write in more details about one of them, wxNativeWindow here in the near future.

The next goal is to release 3.0.3 to make at least some of the bug fixes, if not the new features, from 3.1.0 available to people using the system packages under Linux or just too cautious to start using the "development" releases (even although in my opinion this is not really justified as, on average, 3.1 branch has fewer, not more, bugs than 3.0.x one). As for 3.1.1, this will depend on how quickly the changes accumulate in the master, we'll see how it goes. In the meanwhile, we hope that you'll enjoy the new release!

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!