Thursday, September 11, 2014

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.

Saturday, August 16, 2014

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!

Wednesday, August 06, 2014

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="">
  <PropertyGroup Label="UserMacros">
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '10.0'">vc100</wxCompilerPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '11.0'">vc110</wxCompilerPrefix>
    <wxCompilerPrefix Condition="'$(VisualStudioVersion)' == '12.0'">vc120</wxCompilerPrefix>
  ... the rest of wx_setup.props unmodified ...

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!

Thursday, July 24, 2014

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.

Friday, July 18, 2014

"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...

Sunday, July 13, 2014

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...

Monday, June 16, 2014

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:


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!