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!

3.0.1 released

We have just released wxWidgets 3.0.1, a bug fix release in 3.0 branch. The release files can be downloaded from either SourceForge or our FTP mirror as usual, and as less usual, but is the case for the last few releases, we provide not only the sources and documentation, but also the binaries for the selected Windows compilers.

This release is 100% compatible with 3.0.0, i.e. any code which compiled and worked with 3.0.0 continues to do so with 3.0.1 and so upgrading to 3.0.1 doesn't require any changes and hence is recommended for all 3.0.0 users: basically, without any extra effort on your part (even make or project files don't need to be updated as the libraries use the same names in 3.0 branch), you get more than a hundred bug fixes and improvements.

The release announcement has some details about the changes in this release, but there were really too many of them to list them all, so you should consult the description of the most important changes in the change log directly to really appreciate the scope of the work gone into this release (and the change log doesn't contain relatively unimportant fixes).

Finally, in addition to the bug fixes, if you are using Microsoft Visual Studio 2012 or 2013, there is an extra reason for upgrading to 3.0.1: this release includes the project and solution files for building the library with these compilers, so you don't need to upgrade Visual Studio 2010 projects manually any longer. These projects have been contributed by Artur Wieczorek and I'd like to use this opportunity to thank him for this and numerous other enhancements and bug fixes, especially in wxMSW, as Artur managed to eradicate many bugs that I couldn't fix since many years and is responsible for a good part of the 100+ bug fixes mentioned above. Thank you!

Help with testing 3.0.1

We plan to release 3.0.1 on June 15 (this year, before the jokes start coming in). There have already been a lot of changes since 3.0.0, with many important bug fixes in all three main ports, including tons of corrections to everything bitmap/alpha-related in wxMSW by Artur Wieczorek who managed to eradicate swathes of long-standing bugs, so we'd like to make these improvements available as soon as possible. However we'd also like to ensure that we haven't broken anything since 3.0.0. And while we are relatively confident that the ABI hasn't changed, the behaviour of the code is another matter and some new bug(s) could have been introduced in almost half a thousand commits since 3.0.0.

Which is why it would be really great if as many people as possible could test the 3.0 branch sources before 3.0.1 is done, in two weeks time. Regressions are usually found quite quickly after each release, which is great, but it would be even better if we could find at least some of them before releasing it. So if you are using 3.0.0, please grab the latest 3.0 branch sources using either Subversion (https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_3_0_BRANCH) or Git and let us know if you see any new problems.

Thanks in advance!

Spring Cleaning

Everything comes to an end. Even support for MSVC6, a.k.a. Microsoft Visual Studio 98, which subtly hints at just exactly how old this compiler was. I wouldn't be surprised if wxWidgets were the last open source library to still support it 15 years after its initial release but now, finally, it's over and 3.2 release will require just barely ten year old MSVC7 or maybe even MSVC8 if nobody uses VC7 any more (but up to at least a year ago, some people were still actually using VC6, which is why it was, and remains, still supported in 3.0 release, although with quite some functionality not available for it).

In addition to dropping support for VC6, which was the really important change as it means we can, finally, write the code in wxWidgets itself in something resembling standard C++, we also officially stopped supporting Windows 9x (95/98/ME) in wxMSW port. Windows XP remains supported however as the differences between it and later Windows versions are much smaller than those with Win9x.

Finally, another port bites the dust: this time it was wxPM, the port of wxWidgets to OS/2. As far as I know, neither the port nor the platform itself are used since quite some time and the last real contribution to it dates from almost 5 years ago.

Edit: I am on a tear, since writing the initial version of this post, I've also removed support for the obsolete OpenWatcom and DigitalMars compilers as well as positively ancient (last century) MinGW versions. At this rate, there will be nothing left to remove soon, so I am going to really stop now.

All in all, a good day of work:

% git diff --shortstat master@{yesterday}
 1756 files changed, 12868 insertions(+), 190758 deletions(-)

Accepted GSoC 2014 Projects Announced

wxWidgets is participating in the Google Summer of Code again this year and we are very glad to announce that this year 6 projects have been allocated for us, which is the most we have ever had!

We had many excellent proposals this year and unfortunately even in spite of getting so many slots, not all of them could have been selected, but here is the list of the ones that were:

• Chaobin Zhang will add support for "new" (since Windows Vista) taskbar features under Windows such as progress display indicator, jump lists, buttons and so on.
• Haojian Wu will integrate support for Chromium backend into wxWebView to provide a backend that could be used on all platforms in addition or instead of the native one.
• Mariano Reingart will continue improving wxQt port and will look into the possibility of bringing wxWidgets to Android via Qt bridge.
• Alexandru Pana will work on implementing Direct2D and DirectWrite-based version of wxGraphicsContext, which should result in much better performance and, for text output, quality than the current GDI+-based implementation.
• Nikola Miljkovic will lay the grounds of wxAndroid port: this is the most difficult but also arguably the most exciting project.
• Sun Boxiang will work on improving wxUniv port and in particular make it good enough to be used for simple UI under Android.

As usual, big thanks to Google for organizing the Summer of Code and best of luck to all the students!

Announcing the Great Rewrite

It has become increasingly clear during the last few years that the current wxWidgets code base is simply too out of date for the present day connected, mobile, cloud-based computing world. So, after a deep and careful consideration, we have decided to launch a new project, wxWidgets 2020, which will allow us to remedy this.

The major change to be done in the framework of this project is to switch the implementation language of the library. Clearly, nothing worthwhile can be written nowadays in anything other than JavaScript. While we unfortunately wasted our chance to port wxWidgets to Java in the nineties and thus completely missed the Java desktop revolution, we still can correct this by using JavaScript which, as a language, combines the unparalleled elegance and efficiency of Java with great scripting support (as obviously follows from its name). JavaScript is clearly the language of the future as in addition to the its brilliant success on the client side, it is now even displacing the pinnacle of software engineering which is PHP on the server side, thanks to amazing innovations such as reimplementation of the best features of Windows 3.1 in node.js. Moreover, by using JavaScript we will finally be able to increase the visibility of wxWidgets by hopefully appearing more often in security advisories, which was difficult for us so far due to the total lack of support for XSS and CSRF in C++.

Of course, we, wxWidgets developers, take the backwards compatibility seriously and so we have also thought of a couple of the current users of the library who might have some existing C++ code. Luckily, migrating it to wxWidgets 2020 should be easy to do as you'd simply need to recompile it using asm.js which will be proven to work flawlessly as soon as we test it. And if it ever doesn't, there is always the fall back solution of continuing to run the existing code unchanged inside a virtual machine running inside the web browser -- after all, the modern hardware is largely fast enough to allow doing this, and it would be a pity to keep these CPUs idle.

Finally, the most difficult aspect of this decision was, as usual, choosing the name. After a long and agonizing discussions, we agreed on 2020 which gives us a reasonable amount of time before the release (while releasing wxWidgets 3.0 did take more than 6 years, we are confident that things will happen much faster now that we have the magic of JavaScript at our disposal). And if we miss that deadline, we can always pretend that the name was just a play on "Web 2.0" (only twice as much). As you can see, we have thought of everything. Watch this space!

Looking for project ideas for GSoC 2014

Google Summer of Code 2014 will start accepting applications soon and we plan to submit one for wxWidgets, as we have done every year since 2006. Unfortunately, last year our application wasn't accepted and while technical issues with our GSoC 2013 web site were given as the main reason for its rejection, I think lack of really good project ideas played its role as well. So we'd like to do better this time and try to propose more and, most importantly, more interesting projects to the students.

Coming with the good project ideas is not that simple however, so I'd like to ask for your help, hoping that perhaps it's easier to come up with something new, interesting and original from the outside perspective. So if you think you know some fun to work on, yet useful project that we could propose to the students this year, please let us know -- either in the comments here, or by posting to one of our mailing lists. Let me just remind you that GSoC projects must be about programming and should be realistic, i.e. the task should be such that we could reasonably expect a student to complete it in 3 months of work. And, once again, ideally it should be something students would be motivated to work on.

Looking forward to your ideas!