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!

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!

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!

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.

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!

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!

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.

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!

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!

Being busy without being ugly

wxBusyInfo is one of the classes that it is actually best not to use at all, because it blocks the program UI without allowing to dismiss it, so it is hardly user-friendly and usually performing the long-running operation in a separate thread and providing some way to display its progress and cancelling it in the main GUI thread is strongly advised.

However sometimes doing it is too difficult or maybe even impossible if you are using third-party libraries and in this case wxBusyInfo provides a very simple way to at least indicate that the program is busy, using it is as easy as creating an object on the stack:

wxBusyInfo wait("Working, please wait...", parent);

Unfortunately, traditionally, it was not just very simple, but very ugly as well, as can be seen on this screenshot:

After the recent changes, you can show to the user something more presentable (especially if you use a decent icon):

and with only slightly more effort:

wxBusyInfo info
(
    wxBusyInfoFlags()
      .Parent(parent)
      .Icon(wxArtProvider::GetIcon(wxART_PRINT))
      .Title("<b>Printing your document</b>")
      .Text("Please wait...")
      .Foreground(*wxWHITE)
      .Background(*wxBLACK)
      .Transparency(4*wxALPHA_OPAQUE/5)
);

As you can see, now it's possible to specify quite a few more attributes than just the unadorned message:

• There can be an optional icon in the top part of the window.
• Message is now split in the "text" and "title" parts, with the latter shown in bigger font by default.
• Both text and title can contain markup.
• Background and foreground colours can be specified.
• Finally, the window can be made partly transparent.

To avoid passing all these parameters directly to wxBusyInfo constructor as one unintelligible jumble, a new helper class wxBusyInfoFlags was added to allow specifying them all by names and to make it simple to add more attributes later than needed.

So while the initial advice to avoid the use of wxBusyInfo in the first place remains valid, you can at least make it less ugly now if you do have to use it.

Outdated configure in original 3.0.2

Due to my mistake, 3.0.2 source archives contained an out of date version of configure from 3.0.1. The new archives have with the fixed version have been uploaded now, please redownload if you are using Unix (or configure with MSYS or Cygwin under Windows) and had already downloaded one of wxWidgets-3.0.2.{7z,tar.bz2,zip} files.

Sorry for the inconvenience!

3.0.2 Released

We have just released wxWidgets 3.0.2, please see the announcement for the download links. There is nothing particularly exciting about this maintenance release, but it does fix quite a few bugs and so upgrading to it is recommended to all 3.0 users -- there are no drawbacks to it, as the new release remains both API- and ABI-compatible with 3.0.0.

To give slightly more details, the fixes were mostly in wxMSW, quoting from the change log:

• Fix background of wxRadioBox buttons and wxSlider.
• Fix appearance of wxToggleButtons with non default colours.
• Fix drawing on wxDC when using right-to-left layout.
• Fix wxGrid appearance and behaviour in RTL.
• Fix creating wxBitmap from monochrome wxIcon or wxCursor.
• Fix handling of bitmaps with alpha in wxImageList.
• Add paragraph spacing attributes support to wxTextCtrl.
• Show new style directory selector even for non existent paths.
• Fix order of radial gradient stops.
• Fix font created using wxFont(wxFontInfo()) ctor.
• Fix wxFileName::GetShortcutTarget() in console applications.
• Fix wxFileName::MakeRelativeTo() for shortcut files.
• Fix height of initially empty wxBitmapComboBox.
• Fix setting label of submenu items.
• Fix using Esc as accelerator in the menus.
• Fix wrong initial status bar height in some cases.

And there are also build fixes for Cygwin 1.7, for MinGW 4.8 (we now work around the bugs in its headers) as well as improvements for MSVS projects: the ones for 2005 and 2008 now also include x64 configurations, while the ones for the later versions now reliably build when using parallel build.

In wxGTK, wxSearchCtrl was fixed and doesn't truncate the text and icons inside it any more. There were a few changes in wxOSX as well, including a fix for the use of wxPreferencesEditor.

Finally, in spite of the focus on the bug fixes, there are also a couple of new features in this release:

• wxDateTime::Format() now support POSIX %V, %G and %g format specifiers for week-number formatting.
• XRC handler for wxSimplebook was added.
• It is also now possible to specify the window variant (normal, small, large, ...) in XRC.
• wxGenericListCtrl::EndEditLabel() was implemented, for consistency with the native wxMSW version.

As always, please let us know about any problems with this release and we hope you will find it useful!

GSoC 2014 summary: wxX11/Univ improvement project

The work of Sun Boxiang on improving wxUniv and notably wxX11 port has been merged into the trunk. This was mostly a bug fixing project and as the result of, many more unit tests now pass in wxX11 test suite than before, we're down to "only" 16 failures in 539 tests compared to 80 out of 308 before the project beginning. One new feature also implemented during this project is the new implementation of wxClipboard for X11. See Sun's summary of his work for more details.

Unfortunately there still remains quite a bit of work to be done before wxUniv can really be considered to be ready for general use, but at least know we know better what is missing or broken. In wxX11, there is some major work to be done on event loop code refactoring, to allow reusing the same logic as for the other Unix ports. We should probably also switch to using Cairo instead of the old style X11 drawing functions. And at wxUniv level, we really need a better theme with nicer appearance.

Unfortunately we, the current wxWidgets developers, just don't have any possibility to work on it, so there is no time frame for any of the above, but any contributions from people interested in using wxUniv (e.g. for writing applications with a particular appearance using a custom theme) would be very welcome!

GSoC 2014 summary: Windows task bar API project

This is the first in a series of posts about wxWidgets GSoC 2014 projects and it is about Chaobin Zhang's work on wrapping Windows taskbar API for the use in wxWidgets. The project was a success and I'd like to congratulate Chaobin and thank him and Bryan Petty, who was the mentor on this project, for their work!

The new API additions and things they allow to do are described in more details in Chaobin's own post here, please read it for more information, but, in short, almost all taskbar features are now accessible via wxWidgets API.

Of course, they still remain unportable and Windows-only and while it's better to provide access to them than not do it at all, the main goal of wxWidgets is to facilitate writing portable applications and so the next target is to build a higher level API which would be available elsewhere. We have made a start with wxAppProgressIndicator and wxGA_PROGRESS style for wxGauge using it, but this is still not implemented for any other platform yet. Any contributions implementing this (simple) class in terms of NSProgress under OS X or ideas about how it could be implemented under Linux would be very welcome.

MSVS Versions Poll Results

Two months ago, I've asked about the oldest version of MSVS you were still using. Without further ado, here are the results of the poll:

I admit to have been (pleasantly) surprised by the number of VC12 users. Of course, this poll, as all web polls, is certainly biased because of the absolutely non-random participants selection, but I still want to believe these results and so we'll probably drop (until enough people object very loudly) VC7 support too soon. VC8 is not much more popular, but there are quite few differences between it and VC9 and we'll still keep supporting the latter one for quite some time, so VC8 can piggyback on its support anyhow.

Thanks to everybody who voted!

New MSVS project files

If you try to build the latest wxWidgets sources from Subversion or Git, you may be surprised to discover that the various wx_vcN_*.vcxproj project files don't exist any more. The solution files wx_vcN.sln do still exist (for N from 7 to 12), so if you just use them to build wxWidgets, almost nothing changes for you, but if you use the projects themselves, you will need to use the new ones, without vcN_ part in their name.

Indeed, we now have only one set of projects for VC10, VC11 and VC12 (MSVS 2010, 2012 and 2013 respectively), which is very nice from maintenance point of view and will ensure that all modern, i.e. MSBuild-based, VC projects are always synchronized in the future. It also means that it is a bit easier to customize the projects if you use more than one version of VC at the same time: just copy wx_setup.props file to wx_local.props (this is recommended instead of modifying the former directly as it's under version control and so would appear modified if you do this) and edit this property file. For example, in mine I have

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Label="UserMacros">
    <wxShortVersionString>31</wxShortVersionString>
    <wxToolkitPrefix>msw</wxToolkitPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '10.0'">vc100</wxCompilerPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '11.0'">vc110</wxCompilerPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '12.0'">vc120</wxCompilerPrefix>
    <wxCfg>
    </wxCfg>
    <wxVendor>custom</wxVendor>
  </PropertyGroup>
  ... the rest of wx_setup.props unmodified ...
</Project>

to ensure that different output directories are used for all versions of the compiler. Of course, the other properties can be modified here as well, e.g. you could set vendor to the name of your company if you're distributing custom builds of wxWidgets DLLs.

Other than that, the new projects should work just as well as the old ones, but please let us know if you find any problems with them. Happy building!

Easier way to avoid dependencies on the system installed libraries

When you build wxWidgets under Unix, configure script will by default try using the system versions of the third party libraries, such as libpng, libjpeg, libtiff and so on. Usually this is the right thing to do, as you avoid compiling (potentially a lot of) code which already exists in the ready to use binary form on your system and, more importantly, use exactly the same version of these libraries as other libraries wxWidgets links with, notably GTK+ ones.

However, sometimes you may want to avoid using the system libraries, e.g. because you want to build a statically linked version of your program with as few dependencies as possible. This was always possible by explicitly disabling the use of each and every library with -with-libfoo=builtin, but this was relatively tiresome and it was easy to forget a library or two.

To remedy this, I've just added a new --disable-sys-libs configure option which does exactly what it says: when it is specified on configure command line, only the built-in versions of the third party libraries will be used. This can be useful in the above mentioned static linking scenario under Linux but is probably most valuable under OS X where you never want to have dependencies on any locally installed (e.g. via Homebrew or MacPorts) libraries as this would make the resulting binary impossible to run on other OS X machines.

To summarize, it's a tiny feature, but one which would probably go unnoticed in the 3.1 release change log while I think it could be something useful to quite a few people.

"Invalid parameter" debug messages when using wxGLCanvas

While debugging a problem with wxGLCanvas today, I noticed that every run of the OpenGL cube sample resulted in several copies of the following message in the MSVS debug output window:

Invalid parameter passed to C runtime function.

Now this is an error message just as I love them: it's worrisome enough to make you feel like you ought to do something about it, but without any information allowing you to find out what, actually, should be done. Luckily, there are not that many ways to write to the debug output under Windows and putting a breakpoint on OutputDebugStringA() (surprisingly used instead of OutputDebugStringW() that I tried first) discovered that the debug message was given from deep inside GDI ChoosePixelFormat() function which ends up calling wglChoosePixelFormat() in opengl32.dll which, in turn, calls into ATI driver DLL (atioglxx.dll) which ends up calling _wcscpy_s() with a NULL parameter which is clearly a bug, but it's not our bug.

So, finally the problem is not related to wxWidgets, even if you will see it every time you use wxGLCanvas with (this, buggy, version of) ATI OpenGL drivers. But at the very least I now know that if I see this message again, I can set a breakpoint on {,,msvcrt.dll}__invoke_watson function, using MSVS debugger idiosyncratic syntax, and directly see where does the problem occur. Hopefully this can be useful to someone else too and maybe it will save you some time chasing bugs in ATI code.

Ah, and the original problem which started all this? It turned out to be bogus. Today hasn't been very productive so far...

Some kind of a record

Today we closed two bugs in wxWidgets. Nothing surprising so far, except if you look at the bug numbers and realize that they are two thousand something while the latest ticket in the Trac is 16379. And these bugs were both opened more than 9 years ago, in February and May 2005 respectively. I'm sure that the fact that we are fixing bugs 10 years later must mean something, I'm just not sure what exactly. Do we not care enough about bugs to fix them so late? Do we care very much about them, enough to still fix them after all this time? Are we hopefully short on resources? Are we just very good at allocating our meagre resources efficiently so as to combine both bug fixing and still making some progress (which would never happen if we decided to not add any features until all existing bugs are fixed)? All of the above?

One thing is clear though: please keep reporting bugs in wxWidgets and if they seem to be ignored, know that there is always hope that they will be fixed one day. Next status report coming in 2050...

Which version of MSVS do you (still) use?

As you might know, we've recently dropped support for VC98, and now I've started thinking about which versions of MSVC we should support in wxWidgets 3.1.0 release. Even for 3.0, we only provide binaries for 2008 and later, and by the time 3.2 is out, Microsoft will probably have released at least a couple of more compiler versions, so we will probably have to drop at least it to from the list of binaries by then. I don't really think we are going to fully drop support for it though, doing it for only a 7-8 year old compiler would be quite out of character. But who knows?

And, in fact, I'd very much like to know more about the versions of the compilers that wxWidgets users really use. So here is a small poll, please take a few seconds to click on the earliest version of MSVC that you still use:

surveys

And, if you have any trouble with voting here, you can also do it directly from the poll page.

Thanks in advance!