3.1.0 Is Coming

Although we've been talking about it since quite some time, this time we're really going to make a new release soon. To be even more precise, I firmly expect to make it this month. Of course, I did wait until January was over to announce it. On the other hand, I did not wait for the February to be over neither even though it's the shortest month of the year. On still another hand, we did wait an extra year for this release, presumably just to have one extra day to make it in February of this year, as opposed to the last one... In any case, barring something really catastrophic happening, we should have a pre-release on February 15 and the release some time after that.

Of course, deciding to make the release is not quite enough, there are other things to do too, such as applying at least the most urgent and long standing patches and fixing selected bugs. So this week-end I spent some time doing this and, as the result, instead of 49 3.1.0-critical bugs we now have only 20 of them which is not as good as I hoped, but better than I expected. Of course, some of these bugs were just postponed, while others turned out to be not bugs at all after all or to have been already fixed. Still, quite a few real bugs and, notably, a few regressions which really couldn't remain before the release, were fixed as well, so there is that. I hope to deal with the remaining bugs during the next week and maybe even apply some non 3.1.0-targetted patches too, but in the worst case we could just postpone all the remaining 3.1.0 tickets as there is nothing absolutely critical there (and only a couple I'd characterise as being moderately critical).

So things look cautiously good for 3.1.0 and if we make it according to the plan, thus proving that our new release scripts, updated after the switch to git, work, hopefully 3.0.3 will follow soon afterwards.

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.

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.

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(-)

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.

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.

August Augmentations

August has been a busy month this year, with a couple of new classes being
added and several minor enhancements to the existing ones as well. Even though none of these changes is particularly major, they should hopefully be useful to wxWidgets users, just as they were useful for me when working on my projects.

---

The first of the new classes is wxBannerWindow. As you can see from the screenshot at that link, it is a particularly simple class as it is static in appearance and basically doesn't do anything except providing some information about the current window to the user and, mostly, just looking nice. Of course, it was always pretty simple to do something like this with wxWidgets and personally I had already done it a few times but having a standard class for this makes using it even easier, especially as it can also be defined in the XRC resources and so added to your existing dialogs very easily.

---

The second new class is actually not really a new class at all but a wrapper for an existing one: wxTreeListCtrl is a façade for wxDataViewCtrl which is not nearly as flexible as the full wxDataViewCtrl class but is much easier to use in a special yet common case when you just want to have a multi-column tree control, optionally with icons and, also optionally, check boxes, in the first column, like this:


What you can't see on the screenshot is that the source code of the new treelist sample is much simpler than that of the dataview sample. Of course, this simplicity comes at a price: you can't have "infinitely" many items in this control because it stores all of them internally. However if you have a control with relatively few (not more than a couple of thousands) items, then this is probably not a big problem and this control can be a simple alternative to wxDataViewCtrl. And, of course, wxTreeListCtrl features are a union of those of wxTreeCtrl and wxListCtrl and so it may also provide a simple solution if you're currently using one of those controls but need the extra features (multiple columns or hierarchical items) not available in it.

---

And then there were several enhancements to the existing classes:

• Navaneeth has contributed a useful wxTextCtrl::PositionToCoords() method allowing to find the pixel coordinates of the given character in wxTextCtrl. This allows to show auto-completion window at the right position, for example.



• wxMessageDialog and, hence, wxMessageBox(), have gained support for wxHELP button. Beyond the ability to provide help in your message boxes this is significant because you can now have up to 4, instead of 3, as before, buttons in your message boxes. And as using SetHelpLabel() you can set arbitrary text for this button, it means you can now propose more choices to the user if really necessary (an advance warning: 4 is as high as it will go).



• A new wxTextEntry::AutoCompleteDirectories() was added. Unfortunately, just as AutoCompleteFileNames(), it is currently MSW-only. But at least on this platform it makes using controls used for entering directory names in them more convenient for the user. Moreover, wxFilePickerCtrl and wxDirPickerCtrl now call the appropriate completion function automatically for their integrated text control and so you don't even need to worry about not forgetting to do it yourself if you use one of those handy controls.



• Another MSW-specific change is the addition of wxTopLevelWindow::MSWGetSystemMenu(). This function can be used to add items to the "system" window of Windows programs. Using it is inherently not portable but can still be useful even in cross-platform applications: for example, you could use it to add an "About" item to the system menu under MSW if your application doesn't have any normal menu bar. This is actually consistent with OS X where all applications have the standard "About" item in their "Apple" menu, whether they have a menu bar or not. Maybe in the future we will provide a higher level interface for this but for now this function can be helpful.



• Some cleanup was done as well: SetImageList() and AssignImageList() now work consistently for all controls, as discussed in this thread. And wxDataViewCtrl::GetSelection() now works consistently in all ports, after the changes proposed here were implemented. New, more clear, wxComboBox::IsTextEmpty() and IsListEmpty() were added to replace IsEmpty() whose behaviour was inconsistent in different port. Finally, Stefan fixed long-standing issue with Ctrl vs Cmd keys confusion in wxOSX after this discussion.

---

More new features are planned for September too, notably I'm personally planning to add a new wxTimePickerCtrl class and also wxBalloonTooltip. Any help with their development or participation in discussion of the API of the new classes is always welcome on wx-dev.

Markup in control labels

As I'm hopelessly out of date with my planned updates anyhow, I've decided to write a brief post about a nice new feature that was recently added to wx instead:

This feature is the possibility to use Pango-like markup in some wxWidgets controls, notably wxButton and wxStaticText. This means that it is now possible to write

wxButton *b = new wxButton(parent, wxID_ANY, "");
b->SetLabelMarkup("<span size='x-large' color='blue'>Big</span> <b>bold</b> button");

and it will indeed behave as expected:


Currently this works for wxButton in all major ports and for the wxGTK and the generic versions of wxStaticText (that can be used under all platforms if this feature is important). The plan is to extend this to more controls later, e.g. wxCheckBox, wxRadioButton or wxStaticBox and maybe even allow using markup for the items of controls with multiple items such as wxListBox or wxComboBox. There is however no definite schedule for this so if anybody is interested in using markup with these controls, please consider helping with implementing it, it should be pretty simple to do by simply copying wxButton behaviour.

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.

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!

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

Spring News

Unfortunately I didn't have time to write the April summary until the second week of May and by then it seemed too late so I decided to postpone it and write a combined April-May one. As usual, postponing things doesn't make them easier however and now I find myself unable (due to all the usual reasons of lack of time, partly due to real life getting into the way) to write the May summary properly neither. But better something than nothing so let me just make a very short one.

Most of the activity in wx development community during this time was centred around 2.9.0 release. It still didn't happen but we're now at release candidate 4 and it looks good -- or at least good enough to not justify postponing 2.9.0 any more -- so the final release should be expected very soon. Of course, if you haven't tried 2.9.0-RC4 (or bz2 version if you prefer a much smaller download) yet you're strongly encouraged to do it and post your feedback to wx-users mailing list.

Speaking of the mailing lists, this was the most important administrative change in our recent history: all the lists (including wx-users and wx-dev) have migrated to Google Groups as the current (virtual) server didn't hold the charge any more resulting not only in disruptions to the mailing list traffic but also to frequent Trac outages as everything on that machine slowed down to a crawl due to Postfix bogging all the disk bandwidth. Some people disliked this change but from our point of view there was simply no other solution as switching to Google Groups was much easier than paying for a better server and administering it ourselves.

The only drawback of switching (so far) is that we still don't have any solution for the gateway between wx-users and comp.soft-sys.wxwindows USENET group. Unfortunately Google Groups don't provide this feature and so someone still needs to host this gateway -- if anybody reading this can volunteer either resources or at least information about how to do it, it would be great.


Other than that the usual cycle of adding new features and fixing old bugs continued. Among the features I can remember the following additions:

• Status bar tool tips shown when the text is truncated.


• Better integration with the standard streams (thanks to Jonathan Liu): now you can wrap any wxStream as a std::stream and/or std::streambuf (we still need a way to wrap any std::streambuf as a wxStream to achieve perfect interoperability).


• XRC improvements: wxListCtrl columns and item can now be defined directly in the resource files which is very convenient, especially for the columns (thanks go to Kinaou Hervé). And wxImageList support which was added to allow this is also available for the other controls using it such as wxTreeCtrl and various wxBookCtrl-derived classes.


• A new wxMouseEventsManager class was added to abstract mouse handling in controls with items -- it doesn't seem like much but actually handling the mouse events properly, including respecting users mouse sensitivity options, is not that trivial. It still remains to modify the existing code in generic wxListCtrl, wxTreeCtrl and wxDataViewCtrl implementations to use it.


• An already existing but private until then wxTextWrapper was promoted to a public class status.


• More wxGrid tweaks: it's now possible to selectively disable resizing of individual rows or columns (despite the incredible (and confusing) richness of wxGrid API you couldn't do it before: it was all or nothing only).


• Laurent Humbertclaude has submitted a patch adding table border width support to wxHtmlWindow which allows to have visually nicer tables in wx applications.

Finally, the GSoC projects seem to be all getting into their stride nicely. I don't know much about the other two ones but I'm very satisfied with the progress of the one I'm mentoring. Moreover, it seems that Bartosz is going to add some important enhancements to wxEventLoop which are not part of file system events notification project strictly speaking but which would be very useful to any wx applications which need to monitor anything at all (to be more precise, any file descriptor, HANDLE or CFRunLoopSource depending on the platform) while running.


That's all for today -- and I'll try to find time to write more about June changes and also to finally finish my long promised and long overdue post about Bind() soon.

Marching Forward

Here is a brief and late report of changes in wxWidgets in March. Somehow it looks that once again not that much happened, although it certainly seemed like a busy month. But most of the effort was spent on not very sexy activities such as bug fixing and release preparation -- and 2.9.0 was finally postponed to mid-April in spite of all that so I can't even boast about a new release this month. This was a bit of disappointment but OTOH we'd like 2.9.0 to be usable in production, the ominous zero at the end notwithstanding, and so we decided to release it slightly later but with less problems.

Personally I was also upset by not managing to finish my work on debug/release builds unification before 2.9.0. I did check in the changes introducing wxDEBUG_LEVEL which allows us to more flexibly configure the presence of assertions and other debugging helpers in your build, but the default behaviour didn't change yet, it will now have to wait for 2.9.1 as we didn't want to postpone 2.9.0 for that long neither.

A lot of time was also taken by preparation for GSoC 2009 and discussion of proposal ideas first and the proposals themselves later. This is definitely not time wasted though as we have more proposals this year than the last one (although about the same as the years before) and, most importantly, their average quality is much higher so I'm really looking forward to working with students this year.

Anyhow, in short here is what happened at wxWidgets code level:

• Added wxTextEntry::SetHint() which can be used to show a hint string (e.g. "Search") in an empty text control or combobox. This uses native XP/Vista support if available or a generic fallback otherwise.


• Made wxFTP logging more flexible with wxProtocolLog (thanks to troelsk). We also should extend this to wxHTTP in the future.


• wxSP_WRAP support was added to wxSpinCtrlDouble and wxSP_ARROW_KEYS was fixed too; alignment flags are now honoured for both it and plain wxSpinCtrl (thanks Andrew Radke).


• wxImageHandler can now have more than one associated extension making it finally possible to use both .jpg and .jpeg (Ivan Krestinin).


• Events for wxComboBox popup drop-down and close-up were added (Igor Korot).


• wxString::ToCLong(), ToCULong() and ToCDouble() were added.


• Many fixes to wxDateTime parsing methods which were broken in variously entertaining ways after rewriting them to use iterators instead of string pointers some time ago. wxLocale::GetInfo() was extended to return various date and time formats in the process and as the result all our wxDateTime unit tests finally pass in all locales.


• A bad and long standing bug 9638 introduced by Unicode-related changes was finally fixed. Several other bugs related to handling of embedded NULs in wxString were fixed as well. And all string unit tests pass too in all builds (wchar_t, UTF-8, ...) now.


• XRC error reporting was significantly improved, now the line number is given in error messages.


• wxDocView code was streamlined a bit more and made less surprising to an unsuspecting application programmer.


• Several wxAUI bugs were fixed as Ben had some time to work on it recently.


• Many OS X enhancements/fixes from Stefan and Kevin Ollivier.


• And some wxDataViewCtrl improvements from Robert, as usual.

The previously mentioned Bind() function was finally finished and documented and I'll describe it in more details in a separate post soon.

The usual monthly stats: 732 commits, 137 new tickets and 101 closed ones (oops, no bragging about moving in the right direction this time).

And that's all for now, hopefully we'll have more meaty news next month with a flurry of commits which habitually accompany the end of release freeze period.