Autumnal Tidings

I let slip the October post about the changes in the previous month so let me make this one, about combined changes in September and October, on time to try to compensate for it.

Many things have happened during these two months but the most important one was arguably the official 2.9.0 release. It's just the first release in 2.9 series and so many things will change (and already have changed since then) but it's still significant as it's our first non bug-fix release since 2.8.0 almost 3 years ago and the first one containing Unicode-related changes as described here, and, in much more details, in the updated Unicode overview in the manual (make sure to read about the changes since 2.8 if you're upgrading). Now you can easily download it and try it out if the idea of using an svn snapshot makes you nervous. Please do let us know about any problems you encounter when porting the existing code working -- it's not too late to do something to make it easier to upgrade to 3.0 but we need to know about the problems in order to fix them!

The rest of the changes were the usual mix of bug fixes (many) and feature improvements (a few). One of them stands out though: the long spoken, discussed, argued and even blogged about unification of the debug and release builds was implemented soon after 2.9.0 release. As with the Unicode changes, we're confident that it's for the better but it is also quite possible that these changes have introduced some problems in the existing projects/makefiles. And again, if you let us know about them, we'd do our best to fix them before the final 3.0 release.

As for the new features:

• 2 of the 3 GSoC branches have been merged into the trunk so now wxRibbonBar and related classes as well as wxFileSystemWatcher are available in it.
  
• New wxAny class by Jaakko Salli was added. This is a modern, more efficient and safer replacement for wxVariant and the name was chosen because of the similarity to boost::any. It is not used by wxWidgets itself yet but we hope to provide a bridge between it and wxVariant in the future and start using the new class in the API once all the problems with it are ironed out.
  
• wxInfoBar GUI control was added. Instead of describing it, it is probably enough to show how it looks: there are two test bars in the dialogs sample now which can be shown or hidden using the menu commands but I'll spare you YouTube videos showing the effect and will just paste in three screenshots:
  ,
  
  (this is the native GTK+ version available with GTK+ 2.18 and later only, with earlier GTK+ it would looks similarly to the other platforms, notably it would show icons and position the buttons horizontally -- I have no idea why does the native implementation stack them vertically which looks rather ugly IMO) and
  
  
• Many improvements in wxOSX/Cocoa port. Among cosmetic (but nice) things was the addition of ShowWithEffect() implementation, among less visible ones the addition of more conversions from various NSTypes to wx equivalents which makes developing wxOSX itself simpler. There were also improvements for iPhone (notably OpenGL-related ones) and fixes for 10.6. On a personal note, I started using Cocoa port instead of the Carbon for all new Mac development as I believe that it's in a good enough shape to be used now and prefer to fix any bugs in Cocoa code which will be used in the future and not in Carbon port which won't.
• As usual, wxDataViewCtrl and related classes also received several bug fixed and improvements.
  

As usual, I won't describe the bug fixes in details but will just say that many of them were fixed both in the trunk and 2.8 branch so we'd really appreciate more testing of the current 2.8 branch in svn as the problem with fixing so many bugs in the stable branch is that this might inadvertently break something else and it would be great to find and fix it before 2.8.11 release rather than after it.

I will omit the statistics section this time as there doesn't seem to be much point, it doesn't change much from month to month, let me know if anybody was interested in it.

Well, that's all for now -- better brief than late.

Debug Build Changes in wx3

This series of several recent commits finally implements important changes to debugging support in wxWidgets which we planned to do since a long time. To understand them better, it's probably helpful to say a few words about how the things worked until now, in 2.8 and all previous versions up to the recently released 2.9.0. So far we had two distinct builds of the library: a debug one and a release one. This should be familiar to Windows programmers as the dominant IDE under this platform uses the configurations with these names by default since many years but let me list the differences between the two for the benefit of others:

1. Assertions are only enabled in debug build and disappear completely in release one: this is true both for the standard assert macro as it expands to nothing if NDEBUG is defined (which it is in release) and was also true for the wx macros such as wxASSERT which expanded to nothing unless __WXDEBUG__ was defined (and it was defined in debug builds only).
2. Moreover, at least with the MSVC compiler, debug builds use the special debug version of C run-time library which not only has the asserts enabled in it but also has additional checks, notably very useful memory leaks and integrity checking which are not done in release builds.
   
3. Debug information is only generated in the debug build on the (not quite correct as we'll see below) assumption that you don't need to debug the release build anyhow.
4. In debug build, optimizations are turned off, including function inlining: this can have dramatic consequences for the performance of C++ code which uses a lot of trivial inline functions and adding a function call overhead to them means that the debug build is usually too slow to be used normally.
   

As you can see, this mostly makes sense for the programs. However it doesn't really for the libraries that these programs use as there are good reasons to use a release version of the library even in debug build of your application: e.g. you may want to to avoid getting slowed down by the lack of optimizations in the library code. And, conversely, you may want to have some debugging features even in the release build: assertions may still be useful (although they probably need to be handled differently) and debug information is invaluable when debugging crashes in production builds of your software (notably using the mini dumps produced by wxDebugReport). The debug/release separation is a heritage of the days when every CPU cycle and every byte on the disk counted and so production versions of the software couldn't allow to have any debugging checks in them but these days are long gone and being able to find a bug quickly is well worth the slightly increased library size and unmeasurable drop in performance.

Further, in the Unix world it's almost unheard of to have two versions of the library -- just check whether you really have two versions of any of the libraries used by wxWidgets itself, such as libpng, libjpeg or even different GTK+ libraries themselves. Nevertheless, at least the GTK+ libraries do provide some assert-like error checking even in the release build and you also can download a separate package with the debugging information for these libraries with many Linux distributions. In other words, they have the advantages of the debug builds without many of the problems.

And this is exactly what we have now for wxWidgets too. We still have two different builds under Windows because of the point (2) above: debug builds of the applications use debug CRT and so they must use a special build of the library which was also compiled with the debug CRT or unpleasantness (in the form of heap corruption when memory allocated by one CRT version is freed with another one) is sure to result. But this is the only difference between the two builds now. In other words, the "d" suffix in the library name now indicates only that it uses the debug CRT. Accordingly, the "d" suffix is not used at all under Unix (including OS X) as there is no debug CRT library there. This shouldn't be a problem from compatibility point of view as wx-config output has been adjusted to use the new libraries names so if you use wx-config in your makefiles nothing should need changing -- and if you don't, you really should consider using it. Under Windows the libraries names didn't change at all, of course, so there is no need to change anything neither.

On the other hand, the behaviour of the release version did change. All the details are explained in the updated debugging overview but, in brief, the main difference is that the asserts now remain in the release build too. They can be compiled out completely by using --disable-debug configure flag or setting wxDEBUG_LEVEL to 0 in wx/msw/setup.h explicitly under Windows but there should be no need to do this because by default the asserts are dormant in the release build of the application while they continue to produce the usual message boxes in case of an assertion failure in the debug build (again, of the application, not the library). In practice this means two important things:

• Under Unix you can now use the release version of the library when developing. Unless you define NDEBUG when building your own code, the asserts will be generated just as they were before when you used the debug version so you will still profit from early error detection if you use the library in a wrong way. But you won't be hampered by slow operation of the library itself and you won't need to switch to another version for the release builds. Under Windows you still will need to do it, again because of the point (2), so nothing much changes there from this point of view.
• But under both platforms you can now also enable asserts detection in the release builds. It is entirely up to you whether you're going to do it but personally I strongly recommend at least logging the assertion failures as they do indicate a problem in your code and may be valuable when trying to diagnose the problems your users experience. Showing the message box to your users is almost never the right thing to do though so you will want to define your own assertion handler using wxSetAssertHandler() function.

Inquiring readers may wish to know how is the magic with asserts being enabled for only debug builds of the application code is achieved. The answer is that wxWidgets fiendishly injects a bit of its own code into your application as part of IMPLEMENT_APP() macro. As it is compiled as part of your program, it can do different things depending on whether NDEBUG is defined or not in your makefile and it only disables the asserts if it is. Of course, it also means that if you don't use this macro in your code you do need to use wxDISABLE_DEBUG_SUPPORT explicitly as by default asserts are enabled.

There are two other, less important but still nice, things which have changed in the release build of wxWidgets: debug logging, i.e. output produced by wxLogDebug() and wxLogTrace() functions now remains in it too. Just as the asserts, it is disabled by default meaning that the cost of having the debug statements remaining in your code is extremely slight as their arguments are not even evaluated any more until you call wxLog::SetLogLevel() to enable it -- but you may do it if you need it.

And, finally, debug information is now generated for the release builds as well for MSVC. This is very useful if you use wxDebugReport as without it the dumps produced by it are mostly useless and doesn't have almost any drawbacks, in particular the executables size doesn't increase at all as the debugging information is generated in the separate PDB files so just about the only price you pay for this is the increased disk space consumption which shouldn't matter much in our days of multi-terabyte disks. We also plan to enable debug information for Unix builds in the future but we need to modify the makefiles to also produce it in separate files, just as MSVC does it, first.

To summarize, nothing much has changed for you, wxWidgets user, by default, and if you hadn't read this blog entry (which is excusable, especially considering its length) nor the list of important changes in docs/changes.txt (much less so!) you might not notice that anything has changed at all. However after reading this you should also know that you now have the additional flexibility of being able to enable asserts and/or debug logging even in your production builds and that you can use the same wxWidgets libraries both for development and production under Unix.

August News

An even shorter post than the one for the previous month as nothing much seems to have happened in August. Personally I mostly worked on other projects using wxWidgets and didn't have time to do much on wx itself and didn't even have time to finish my wxInfoBar contribution which was supposed to be done back in July. So it was mostly bug fixes and cleanup with some minor new features mostly contributed by others via patches on Trac.

August also marked the end of the GSoC. I'll try to write more about wxFSWatcher (or maybe invite Bartosz to write about it himself) later, when I integrate his work in svn trunk and would also like to invite other mentors to write about the projects they were involved in too but for now let me just say that all 3 projects were successful, so you can look forward to new wxRibbonBar and wxFSWatcher classes and AUI improvements in the next wx version.

Another good news is that people are working on using wx under several new platforms: this month we had posts about wxSymbian again (wxBase part only, no GUI yet), wxQNX (apparently wx already works under QNX in fact, although I don't even know which port does it use) and someone is writing a wxAmigaOS4 port. Personally I'd be most interested in the first one of those but more ports is always fun to have, even if AmigaOS is unlikely to ever become as popular as its predecessor was again.

The usual statistics for committers:

1. Vadim Zeitlin (106)
2. Jaakko Salli (11)
3. Stefan Csomor (10)
4. Mike Wetherell (5)
5. Paul Cornett (4)
6. Julian Smart (3)
7. Bryan Petty (1)
8. Jouk Jansen (1)
9. Kevin Ollivier (1)

show that the usual suspects were at it again: I was mostly checking in patches by others, Jaakko working on wxPropertyGrid and Stefan fixing bugs in wxOSX. Paul fixed a pretty bad bug in wxGTK which prevented it from working at all under Fluxbox WM (actually it was apparently a Fluxbox bug but users probably don't care about such fine distinctions).

101 new Trac tickets were created, 92 were closed but 10 were reopened so we seem to be in the red again -- but then it seems like it is the case every month so it's not very surprising any more.

July Summary

Another month, another post about progress in wxWidgets development. The most important recent change was covered by a separate post recently and I won't return to it but just say that wxLog is much nicer to use now in general and it's possible to use it effectively in multi-threaded programs, unlike before.

Other changes were mostly bug fixes (including a few important ones in wxSocket, but unfortunately it still seems broken under Mac, so I'll have something to announce the next month :-) and minor feature improvements. A huge patch globally replacing all occurrences of _T() macro with wxT()was applied so we finally got rid of one nastiness in wx code which is always nice (_T() is still available for user code for compatibility reasons though). And I also started working on wxInfoBar but it isn't quite done yet so this will be something for the next month again.

Except for this the most exciting new development wasn't actually in wxWidgets itself at all but outside of it when Ben Williams (AUI author) announced wxWebConnect availability. I didn't have time to try it myself yet but it definitely looks very promising and should allow to easily embed a modern HTML rendering engine (Gecko in this case) in wxWidgets applications. This opens quite a few possibilities, especially with the new features of HTML5 some of which are already implemented in Gecko.

As for the rest, as I can now use git as wxWidgets svn client, I also can use git shortlog which makes writing summaries simpler, e.g. here is the number of commits to the trunk per author:

1. Vadim Zeitlin (129)
2. Stefan Csomor (22)
3. Jaakko Salli (14)
4. Kevin Ollivier (4)
5. Mike Wetherell (3)
6. Vaclav Slavik (3)
7. Jouk Jansen (2)
8. Paul Cornett (1)
9. Robert Roebling (1)
   

So you can see that in addition to my own changes which I described above, some work was done on OS X port and wxPropertyGrid. What can't be seen from here is that there were also several changes on 2.9.0 branch and a lot of ones in the topical GSoC branches.

Finally my script for analysing Trac statistics reports 109 new tickets and 67 closed ones of which 8 were reopened. So our goal of closing all the tickets didn't advance much this month neither -- help with them would be welcome!

Playing with DVCS for wxWidgets

Just wanted to share my recent experiences with trying to use a DVCS for wx. I was interested in this because I often need to test some change on multiple platforms before committing it and currently what I do is to do the modification in a svn checkout on one machine, test it there, then make a patch, apply it to svn checkout on another one, test there, then commit from the first one, undo the patch on the other one and update from there -- this is not really complicated but certainly involves many more steps than I'd like. And this is the simple case when the patch actually works, if it doesn't and if you need to make changes to it, it's too easy to get entangled in multiple copies of the patch and get lost.

On the other hand, I'm using since some time Mercurial (also known as hg) for my own projects and enjoy its simplicity and how easy it is to create a separate clone of the repository for the changes. It's also so much faster than svn for a lot of common operations such as viewing the file history, annotating it or finding a given log message (which it can do by keyword, unlike svn). So I decided to try using hgsubversion, a bi-directional Mercurial-SVN gateway, for wx.

Unfortunately it didn't go great. Importing wx tree took a long time (~30 hours) and ran out of memory a few times as reported here, resulting in the process being killed by Linux out of memory killer (one of few times I've been actually glad to have it happen as a process consuming 8GB of memory without any good reason does deserve to be killed). Of course, this is a one-time only operation and so it doesn't matter much but, still, it was hardly a great start. More importantly, though, working with this setup turned out to be inconvenient in practice because cloning the entire wx tree does take time, even with hg efficiency, especially to a different machine. It can hardly be otherwise considering that the full cloned tree is 1.7GB -- it's not that much in absolute as svn checkout of the trunk (only) is 330MB, while hg tree contains all project versions and not just the latest one, but it's still a lot and, as we'll see below, it can be much better.

An alternative could have been to use Mercurial named branches but they are not meant for the private changes, i.e. using them would leave traces in svn history which is really not ideal (these branches are for my own personal testing and I do not want the others to see how many mistakes I made while doing a trivial change!). Or there is Mq extension which is supposed to be one of the greatest things about Mercurial but unfortunately I could never get used to it and it just doesn't seem right to me to use what is basically an orthogonal VCS on top of the one which is normally used. And the patch queue is local to each repository so with it I'd basically be reduced to copying patches around again. Maybe the most promising extension is the pbranch one, it really does seem to allow to do what I need. But it's non-standard, I'm unsure about its further prospects and it seems rather complicated thus negating the main advantage of hg -- its simplicity.

So, with a heavy heart, I turned to another popular DVCS: Git. I think it could be described as Mercurial evil cousin. While Mercurial is as easy to use as it could be and has great documentation, Git is almost perversely complicated. It has concepts which are particular to it only (can anyone really explain what purpose does the index existence serve except for confusing new users and occasionally tripping more experienced ones?). Its included documentation is only useful if you already know very well what you are doing. It allows (I think it encourages, really) you to make errors -- which is, of course, fine, as there are 3 or 4 different ways to undo them. Of which 2 (different ones, depending on situation) make things even worse. It seems to enjoy reusing commands commonly used in other VCS to do something different. Even the commands which seem to do what you'd expect (e.g. pull and push) do not. Moreover, they are not really even opposites of each other. So you never know what a command with a simple name does and you never risk finding any other commands without reading half a dozen of git tutorials. And even then you have to remember that the equivalent of hg histedit is git rebase -i (with rebase in general doing something completely different, of course). And using git means having one extra letter to type for every command compared to hg!

So ever since I found Mercurial I never seriously considered using Git. While I agree that Git is more powerful, having 37 different ways to shoot oneself in the foot is not really what I'm looking for in my VCS. Unfortunately, Git does have one killer feature: local branches. This is exactly what I need when working with wx svn and is close to what Mercurial pbranch extension does. Except, in this particular case only, Git is actually simpler. And faster.

Speaking about faster: importing wx svn using git-svn took "only" 12 hours. And never consumed any appreciable amount of RAM. And, a really pleasant surprise, the git repository of wx is only 400MB -- that is hardly bigger then svn checkout of a single trunk revision (while git repository, like the hg one, contains all versions of all branches in the project) and more than 4 times smaller than hg. In spite of myself, I was impressed. Think about it: this means that if you have both 2.8 and trunk checkout of wx you actually save 200MB of disk space by using Git -- while gaining all the advantages of having the entire project history locally (which is the reason for which switching between 2 branches in git is practical but using svn switch is not). And if, like me, you have 4 branches checked out (2.8, 2.9.0 (well, hopefully not for much longer, this one), SOC2009_FSWATCHER and trunk), the space savings becomes really noticeable (almost 1GB).

But it gets better: "cloning" (creating a new local branch) with git is instantaneous. Switching to another existing branch (e.g. 2.8 one) is much faster than with hg. Even updating from svn seems to be faster, although here the difference is not really significant (using the usual hg pull instead of git svn rebase is significant advantage of Mercurial though -- but unfortunately it's easier to get used for idiosyncratic syntax (yeah, and committing is done with git svn dcommit -- I'm sure there is a logical explanation for this extra "d", too...) than to slowness).

So I'm using git as my svn client for now (all of 2 days). And I'm ashamed to say I love it. Of course, hg is great compared to svn too. But I can't realistically use it with svn right now and I can do it with git. And so I don't have to jungle with patches any more. And the coloured output of git diff is so much easier to read than svn diff (and even than hg diff with colour on, as git also nicely highlights white space errors). Now if only I didn't forget to use that --cached option half of the times...

To summarize, I wholeheartedly recommend using Git as a client for wx svn repository. If there is any interest in it, I could push my repository to Github (it's bigger than their 300MB limit for free plan but I hope they could make an exception). But even if you need to run git-svn yourself, it's still great to have a local git repository if you plan on submitting (or even just having them privately) patches to wxWidgets. Of course, any DVCS could be used to have this extra freedom of working with wx in any way you want. But while I still hope hg implements local branches in the future and hgsubversion improves (there doesn't seem to be much point in hoping that git interface becomes logical), for now Git is the best choice of a DVCS to use with wxWidgets.

Blogging about logging

I've just finished a series of changes which were meant to make wxLog less embarrassing and more useful. Of course, wxLog was always meant to be a simple logging framework adapted for typical logging patterns of GUI applications but there is such thing as being too simple and it became apparent since quite some time that wxLog was insufficient for any kind of application using multiple threads or even simply separated in multiple components whose logging should be controlled simultaneously. And as most applications nowadays do use multiple threads, this is a serious limitation indeed.

As an aside, when I realized that the deficiencies of wxLog really prevented it from being useful in the application I was working on, my first idea was not to enhance it but to switch to another, dedicated logging library. But incredibly enough I couldn't find any good candidate: there are tons of libraries based on log4j but translating Java API in C++ is really not a good idea and I hoped to find something more idiomatically C++-ish. So I naturally turned towards Boost and found not one but two libraries named "Boost.Log", with one even confusingly called "Boost.Log v2" despite being older than the other one. Unfortunately, while both of them are undoubtedly great libraries, I was completely overwhelmed by their complexity. They are certainly great and allow some things I wouldn't even think of if I were creating a new logging library from scratch, e.g. a possibility to associate a decrementing counter starting from 100 with step of -5 with every log record which is extremely impressive but also doesn't seem to be especially useful in practice and I'd prefer to just simply use a logging library instead of admiring its marvellous elegance. So I passed them too -- and decided that while wxLog might be too simple, keeping it simple enough was still very important.

With this in mind, I decided to simply fix the few most glaring omissions in wxLog:

1. Lack of support for logging from threads other than main.
2. Impossibility to treat logs from different parts of application differently.
3. Absence of __FILE__, __LINE__ and __FUNCTION__ information.
   

The first one was already solved for some logging targets, e.g. wxLogWindow was already thread-safe as it collected the messages coming from other threads and really displayed it in its text control only during the idle time from the main thread. All I did was to extend this approach to all log targets by moving its implementation in wxLog itself.

This does introduce a new problem however: as the messages are buffered instead of being output immediately, they could be lost if the program crashes before the main thread has a chance to output them. So I also added a concept of per-thread log targets which can be associated with a single thread only and don't need to do any buffering. Of course, such target can't show messages to the user -- as this can only be done from the main GUI thread -- but it can log them to a file and so a thread can always set up wxLogStderr or a wxLogStream to ensure that its messages are saved in a file as soon as they are output.

On a related note, using wxLogNull (and wxLog::EnableLogging() which it uses internally) now only disables logging for the current thread and not the application as a whole. This makes sense as if you just want to suppress an error message from a wxWidgets function you're going to call, you shouldn't disable all the logs from the other threads of your application which can be doing something completely unrelated while this function is executing. The initial plan was to also add a new way of disabling the logging globally but after thinking about it for quite some time I couldn't find any realistic use case when doing this would be really useful so for now logging can only be enabled thread-wise -- but we can always make it possible to disable it either globally or, which probably makes more sense, on log target basis, if really needed.



The second problem was solved by introducing the notion of "log components". These are simply arbitrary strings which identify the component which logged a message. By default, messages logged by wxWidgets come from the log component "wx" and its subcomponents, that is strings starting with "wx/" like, for example, "wx/net/ftp", while messages generated outside of wxWidgets have empty log component as it's not defined by default. This is already useful as sometimes you may want to treat wxWidgets and your own messages differently, e.g. you could disable all non-error messages from wxWidgets by setting the log level of the "wx" component to wxLOG_Error while keeping all messages, including the debugging ones, from your code enabled. But this feature becomes really useful mostly when you do define your own custom log components. This is done simply by #define-ing wxLOG_COMPONENT before using wxLogXXX() functions. It can be done on the compiler command line (to ensure that the same value is uniformly used everywhere) or inside the source files. In either case you will probably want to use different values for different parts of your application, e.g. "myapp/ui" and "myapp/db" and "myapp/network" and so on. And then you can independently configure the log level for each module and, also importantly, you can distinguish between the messages logged by different components and send them to different final destinations (e.g. database-related messages to one log file and network ones to another) from your overridden wxLog::DoLogRecord().

Finally, to solve the last problem in the list, all wxLogXXX() functions have been replaced by macros with the same names, which allows to record the information about the log message location. It can be retrieved from DoLogRecord() from the wxLogRecordInfo struct passed to it. By default, this information is not used in any of the predefined loggers (yet?) but it's available in case you nee it.

Moreover, in process of doing this, I actually created a relatively generic mechanism for passing arbitrary extra information to the log functions -- but, still remembering my experience of reading Boost.Log documentation, I decided to not make it public for now and to keep things simple.

After all, with the additions mentioned above wxLog is already much more useful and hopefully it's good enough for even complex wxWidgets applications now. And if not, we'd be interested to hear about still missing features, of course, so do have a look at the improved wxLog version in svn trunk and let us know what do you think!

June News

Here is a brief summary of changes in wxWidgets during the past month. Once again, we (and I in particular) didn't do time to do as many things as we'd like to but less is better than nothing. And, in case of the most important new feature added, later is hopefully better than nothing as I seem to remember requests for it at least 10 years ago -- and now, finally, we do finally have ... drums roll, please ... support for images in wxButton:







(the images, and hence button sizes, are different in the screenshots above because the standard wxART_INFORMATION icon is used which is platform-dependent).

Another important even if somewhat technical change was the harmonization of handling of different background styles under all (major) platforms, as discussed here. As a side effect, this allows background bitmaps in wxHtmlWindow to work again in wxOSX/Carbon.

Other miscellaneous changes:

• Some wxFont convenient methods such as Bold(), Larger(), Smaller() and non-const versions MakeBold(), MakeLarger(), MakeSmaller() were added: see "Similar fonts creation" section in wxFont documentation


• There were several additions to XRC:


• wxFileCtrl handler was added (thanks to Kinaou Hervé)


• wxEditableListBox handler was added too


• All existing window handlers gained support for ownfg, ownbg and ownfont tags corresponding to the appropriate wxWindow methods
  


• wxDirCtrl gained support for multiple selections (thanks to Steve Lamerton)


• wxStandardPaths behaviour under Windows is now more flexible, see its new IgnoreAppSubDir() method.


• wxVariant was improved to support wxLongLong.

Speaking of wxVariant, Jaakko is currently working on the new, better, safer and more efficient replacement for it called wxAny. Any feedback about it would be very appreciated as we'd really like to make a class we wouldn't be later ashamed of (which is unfortunately a feeling I often have about wxVariant).

Finally, the usual statistics: there were 418 commits to the repository, 95 tickets were created or reopened and 70 tickets were fixed (hmm, I wonder if the label "progress" is this still applicable?).