Preparing for 2.9.5

As (unfortunately) not unusual, it looks like 2.9.5 won't be released before the end of October as I planned hoped. But the good news is that we're still relatively close to it, so even though the release is going to be late, at least it won't be late by much. This optimistic assessment is based on the fact that a lot of long-standing important tasks are finally getting closer to the completion:

First, we will finally (after 3 years) soon apply the XRC reorganization patch by Steven Lamerton that will allow us to have XRC handlers for the classes not in the "core" or "adv" libraries, e.g. wxRichTextCtrl, wxRibbonControl or various AUI classes. This was unfortunately impossible so far because of annoying inter-library dependencies issues, but will be fixed by this patch in a classic computer science manner -- that is, by introducing another level of indirection. The changes here are relatively straightforward but there are still quite a few of them, so it would be great to get more testing for them, even before 2.9.5 release, so if you're interested, please get the patch from the Trac or, soon, from the svn or its git mirror and let us know about your experience.

Second, an almost as long-lived branch containing several important changes to wxAUI by Malcolm MacLeod is also planned for a merge. The main user-visible effect of these changes is that it will now be possible to drag notebook pages not only between different wxAuiNotebooks but also form notebooks dynamically by simply piling up pages on top of each other. There are other notebook-related improvements, such as support for horizontal (i.e. on the left or right) tabs by Jens Lody. But here there are also a lot of changes and, to make matters more interesting, they're hardly straightforward so testing this patch would be very welcome as well.

The final relatively big feature planned for 2.9.5 is wxMaskedEdit by Manuel Martin and, again, unsurprisingly, feedback about it would be very welcome.

In addition to the not-yet-quite-merged patches above, several other long-postponed changes have been already done in the svn:

• Scintilla, used by wxStyledTextCtrl, was upgraded to almost the latest version. This brings a number of new features but also, possibly, some bugs which it would be great to find before the release.
• Much better support for symbolic links in wxFileName (see DontFollowLink() and the new flags argument of Exists()) and wxFileSystemWatcher (work done by David Hart).
• New wxSimplebook class.
• Support for embedding PNG into the program sources, XPM-like.
• wxPython CallAfter() equivalent for C++.

Please test your programs with the latest svn and, better yet, try using the new features in them and let us know about any regressions or things that could be improved in the new stuff.

Thanks in advance for helping us to make wxWidgets 3.0 better!

Spin news

I've recently needed to add a small new feature to wxSpinCtrl: possibility to display and enter the numbers in hexadecimal format. This is done now with the addition of SetBase() method, so now you can either call SetBase(16) explicitly in the code or use "base" XRC property by adding <base>16</base> to your XRC files (this needs to be done manually as dialog editors don't have support for it yet). Just in case you're curious, here is how the new control looks in the updated widgets sample under OS X:

But as a side effect of working on this, I've also fixed a few other bugs in wxSpinCtrl, hence this progress report:

• First, I've simply removed wxOSX version of this control. Strangely enough, we had a generic implementation of it for wxOSX which was different from another generic implementation used for all other platforms. They were not identical but pretty similar and at least now we only have one version to maintain.
• Next I fixed the funny bug with contents of the control being shown as password field if wxALIGN_CENTRE was used. Even though it's more correct to use wxTE_CENtRE, it's more user-friendly to support both versions, especially as the documentation was rather confusing on this subject until recently.
• I also added the generation of wxEVT_COMMAND_TEXT_ENTER to the generic wxSpinCtrl which didn't send them at all before. This fixed another bug as generic wxSpinCtrl was also used for wxSpinCtrlDouble under wxMSW, and so this event wasn't sent when using real-valued spin controls under Windows, even though it was sent with integer-valued ones.
• But integer-valued Windows wxSpinCtrl was not without problems neither: the value carried by its events wrapped over when it was greater than SHRT_MAX, i.e. 32767. So I fixed this as well.

There are still some bugs left in wxSpinCtrl, e.g. settings colours doesn't work correctly in the generic version but it's in a much better shape now than only a few days ago.

Did you know that Intel VTune used wxWidgets?

Well, I didn't know this but reading the release notes for a new update I've just downloaded I noticed the following at the end of the document:

wxWindows Library
This tool includes wxWindows software which can be downloaded from
http://www.wxwidgets.org/downloads.
wxWindows Library Licence, Version 3.1
======================================
Copyright (C) 1998-2005 Julian Smart, Robert Roebling et al
...

And, indeed, Ctrl-Alt-middle-clicking on VTune window gives:

Sometimes I forget that only a very small proportion of all wxWidgets users reads mailing lists (let alone posts to them), the forums and so on and that there are plenty of companies that use wxWidgets that we have no idea about at all. So it's not really surprising to find that Intel uses wx but it's still nice to have them in our users list!

How to use 2.9.4 wxMSW binaries

We have decided to experiment with providing binaries for wxWidgets releases. So, for the first time ever, 2.9.4 release includes binaries for a few different versions of Microsoft Visual C++ compiler.
However we might not have done a very good job of explaining how to actually use them, the README at the link above is relatively brief and omits some steps, so let me try to explain in more details how to build your wxWidgets applications using the files provided and without building wxWidgets yourself.
First, you need to get the correct files. You will always need the headers one but the rest depends on your compiler version and architecture: as different versions of MSVC compiler are not binary compatible, you should select the files with the correct vc80, vc90 or vc100 suffix depending on whether you use Visual Studio 2005, 2008 or 2010 respectively. You also need to decide whether you use the x64 files for 64-bit development or the ones without this suffix for the still more common 32-bit builds. After determining the combination of suffixes you need, you should download the "Dev" and the "ReleaseDLL" files in addition to the "Headers" one above, e.g. for 32-bit MSVS 2010 development you need wxMSW-2.9.4_vc100_Dev.7z and wxMSW-2.9.4_vc100_ReleaseDLL.7z.

Once you have the files you need, unzip all of them into the same directory, for example c:\wx\2.9.4. You should have only include and lib subdirectories under it, nothing else. To avoid hard-coding this path into your projects, define wxwin environment variable containing it: although it's a little known fact, all versions of MSVC support environment variable expansion in the C++ projects (but not, unfortunately, in the solution files).
Next step is to set up your project to use these files. You need to do the following:

• In the compiler options, i.e. "C/C++" properties:
  • Add $(wxwin)/include/msvc;$(wxwin)/include to the "Additional Include Directories". Notice that the order is important here, putting the MSVC-specific directory first ensures that you use wx/setup.h automatically linking in wxWidgets libraries.
  • Add WXUSINGDLL and wxMSVC_VERSION_AUTO to the list of defined symbols in "Preprocessor Definitions". The first should be self-explanatory (we only provide DLLs, not static libraries) while the second one is necessary to use the libraries from e.g. lib\vc100_dll directory and not the default lib\vc_dll.
  • Also check that _UNICODE and UNICODE symbols are defined in the same "Preprocessor Definitions" section. This should already be the case for the newly created projects but it might be necessary to add them if you're upgrading an existing one.
    [added at 2013-02-08 in response to comments]
  • Check that you use "Multi-threaded [Debug] DLL" in the "Run-time library" option under "Code Generation" to ensure that your build uses the same CRT version as our binaries.
• In the linker options you only need to add $(wxwin)\lib\vc100_dll (with the compiler-version-dependent suffix, of course) to "Additional Library Directories" under "Linker\General" in the options. Thanks to the use of MSVC-specific setup.h you don't need to list wxWidgets libraries manually, i.e. you do not need to put anything in the list of "Additional Dependencies".

Now you should be able to build your project successfully, both in "Debug" and "Release" configurations. With MSVC 10 it can also be done from the command line using msbuild.exe. Of course, to run the generated executable you will need to either add the directory containing wxWidgets DLLs to your PATH or copy the DLL files to a directory already on it. Finally, if you want to distribute the binaries created using these options, you will need to install Microsoft Visual C++ run-time DLLs. Again, MSVC 10 has an advantage here as you can simply copy msvcp100.dll and msvcr100.dll as any other DLL, while you need to install specially for the previous compiler versions that use WinSxS ("side-by-side") for them.
Let us know if you run into any problems using these binaries or, on the contrary, if you didn't but were glad to have them. If enough people find them useful, we'll try to provide them again for 2.9.5 and, most importantly, for 3.0.

---

Updated on 2012-08-23T12:55:10: Corrected linker options instructions.

Nicer Notifications

This is something really not that important in the grand scheme of things but notifications produced by wxNotificationMessage used to look relatively ugly under Unix as they appeared just as a normal window:

And this wasn't especially nicely looking and, even worse, inconsistent with all the other notifications shown by the system.

As I'm currently on vacation and don't feel bound to work on "important" things, I've finally decided to take time to change this. Switching to libnotify to show the notifications as everybody else does was very simple and the end result is much nicer:

or, to show an example of multiple active notifications:

Unfortunately fixing the rest of the problems due to lack of integration with Linux desktop turned out to be less trivial, for example I totally failed in my attempts to get notifications about the system going to sleep and waking up that I'd really like to implement for wxGTK. The only other thing I managed to do during this vacation was a couple of minor wxWebView enhancements but more about this in a future post.

MSVS 2012 RC Installation Experience

As an update to my previous post about building wxWidgets with VC11 beta, I'd like to say a few words about my experience with installing the RC version of the same compiler -- now known as MSVS 2012.

First of all, the installer doesn't tell you anything about having to uninstall the beta yourself before running it but you really must do it. Otherwise the installation will succeed but the IDE won't open afterwards with an "invalid licence" error (see this known issue, apparently beta has a higher version number than the RC).

Second, and much more annoyingly, the installer also doesn't warn you that it's going to break your existing VC 10 installation. This is also an apparently known problem and can be fixed by installing SP1 for VC 10 but if you're unaware of it it may not be completely obvious that the mysterious LNK1123: failure during conversion to COFF: file invalid or corrupt errors you now get when building any MSVS 2010 C++ projects in debug build are due to VS 2012 installation.

Hopefully knowing this in advance will make testing MSVS 2012 less aggravating to the other wxWidgets users than it was for me. Unfortunately you will still need to reboot your machine a couple of times to install it but then clearly not having to reboot for a compiler installation would have been too much to expect.

Ah, and as for building wxWidgets with VC 11 RC -- nothing to say here, it still works, just as it did with beta and I didn't notice any real changes affecting wxWidgets. The new IDE look is pretty ugly but all the features are there and the profiler is rather nice. Pity it's only included in Premium edition and later.

Building wxWidgets with Microsoft Visual C++ 11

This is practically a non-post as building wxWidgets with the recently released Visual Studio 11 Beta turned out to be completely uneventful. After installing the Visual Studio itself -- which was also perfectly straightforward albeit still a typically Microsoft experience as, obviously, installing a compiler should require you to reboot your machine -- I could build the current wxWidgets with the new compiler from command line using nmake /f makefile.vc without any problems. I did fix a harmless warning about an unrecognized Visual C++ version but no other changes were needed.

So far I don't have any experience with the new compiler yet, i.e. there are no obvious differences compared with VC10. It seems to produce slightly larger binaries (~70MiB instead of ~68 for VC10 for wxmsw29u_core.lib) but this is perhaps a consequence of its beta nature. I do look forward to testing the improved support for C++11 in the new version and, if I have some time, I'd like to play with the new WinRT stuff and, in particular, WRL library to see if it's realistic to write Metro applications in C++ without using Microsoft-specific compiler extensions and, if so, whether we can support Metro in wxWidgets.

Panta rhei

I've just done something that I hadn't done during the entire time I was working on wxWidgets: removed an entire port. And not even just one of them but two at once: wxPalmOS and wxMGL. The latter wasn't used since many years and I don't think the former has been ever really used at all. Moreover, the platforms targeted by these ports don't themselves exist any more. So removing them was a pretty straightforward decision as there were no benefits at all in keeping these ports while maintaining them took small but non zero amount of work.

The decision is less clear cut for them but there are other ports which might be dropped soon too. wxGTK1 will probably disappear when GTK+ 3 support is merged into trunk. The old Cocoa port should be removed too, if only to avoid confusion with the new wxOSX/Cocoa. wxMotif is definitely not very relevant any more so it will probably go as well. I'm not sure if anybody is interested in wxPM (OS/2 port) but it could be a candidate for removal in the near future as well.

The one port which we, or at least I, had high hopes for was the DirectFB-based wxUniversal, a.k.a. wxDFB. Unfortunately it hasn't attracted any interest from the community so it has never developed into a fully-fledged port. This is really a pity as I'd like to see wxWidgets used more on low-powered embedded devices where DirectFB is pretty popular and I still hope that we can find somebody interested in working on it. And while there is hope, we're not going to remove it, even if it's really not very useful in its current state.

With all these ports gone or going, what is remaining? The three major ports are, as always, wxMSW, wxGTK(2) and wxOSX. wxDFB, wxX11 and wxWinCE are not used much but still exist in a more or less reasonable shape. We also hope to have wxGTK3 soon and, more excitingly, the new wxiOS port. Other than that, wxQt port was started but seems to have stalled and, in any case, it was never clear if it made much sense. wxAndroid would be the port I personally would most love to see but it requires a big effort and in spite of having been discussed several times nothing much has happened.

I think writing new ports -- or maintaining and improving the existing ones -- is much simpler now than it used to be because of the clear definitions of the classes API (for the most part anyhow), more clear documentation and the unit tests allowing to automatically check the code correctness. And working on your own port is very rewarding and (at least in my, perhaps atypical, opinion) a lot of fun so if you're looking for a fun open source project for 2012, you could do worse than choose working on wxSomethingOrOther!