Tuesday, September 23, 2014

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!

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="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!

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