wxBlog

Panta rhei

2012-01-15T14:49:00.003Z

I've just done something that I hadn't done during the entire time I was working on wxWidgets: removed an entire port. And not even just one of them but two at once: wxPalmOS and wxMGL. The latter wasn't used since many years and I don't think the former has been ever really used at all. Moreover, the platforms targeted by these ports don't themselves exist any more. So removing them was a pretty straightforward decision as there were no benefits at all in keeping these ports while maintaining them took small but non zero amount of work.

The decision is less clear cut for them but there are other ports which might be dropped soon too. wxGTK1 will probably disappear when GTK+ 3 support is merged into trunk. The old Cocoa port should be removed too, if only to avoid confusion with the new wxOSX/Cocoa. wxMotif is definitely not very relevant any more so it will probably go as well. I'm not sure if anybody is interested in wxPM (OS/2 port) but it could be a candidate for removal in the near future as well.

The one port which we, or at least I, had high hopes for was the DirectFB-based wxUniversal, a.k.a. wxDFB. Unfortunately it hasn't attracted any interest from the community so it has never developed into a fully-fledged port. This is really a pity as I'd like to see wxWidgets used more on low-powered embedded devices where DirectFB is pretty popular and I still hope that we can find somebody interested in working on it. And while there is hope, we're not going to remove it, even if it's really not very useful in its current state.

With all these ports gone or going, what is remaining? The three major ports are, as always, wxMSW, wxGTK(2) and wxOSX. wxDFB, wxX11 and wxWinCE are not used much but still exist in a more or less reasonable shape. We also hope to have wxGTK3 soon and, more excitingly, the new wxiOS port. Other than that, wxQt port was started but seems to have stalled and, in any case, it was never clear if it made much sense. wxAndroid would be the port I personally would most love to see but it requires a big effort and in spite of having been discussed several times nothing much has happened.

I think writing new ports -- or maintaining and improving the existing ones -- is much simpler now than it used to be because of the clear definitions of the classes API (for the most part anyhow), more clear documentation and the unit tests allowing to automatically check the code correctness. And working on your own port is very rewarding and (at least in my, perhaps atypical, opinion) a lot of fun so if you're looking for a fun open source project for 2012, you could do worse than choose working on wxSomethingOrOther!

Adding a New Control to wxOSX: A Walkthrough.

2011-12-18T13:21:00.002Z

I've decided to write down my notes about implementing a new control for wxOSX port in the hope that it can help other OS X developers to participate in wxOSX development (but, to be honest, also because I might return to it myself when I have to do this the next time).

So, without further ado, here is the full and unabridged true story [*] of implementing wxDatePickerCtrl in wxOSX/Cocoa.

To start with, you need to set up your wxWidgets development environment. For this you need to get wxWidgets sources, ideally from svn or its git mirror. You then need to build them enabling debug support to make sure you can debug them later. The simplest way to do this is to use the command line, even if you prefer to use Xcode for editing and debugging later. It's strongly recommended to build wxWidgets in a separate directory from the one containing its sources, so, assuming you put the sources in $HOME/src/wx, you should do:


 $ mkdir -p ~/build/wx/osx_cocoa-debug
 $ cd $_
 $ ~/src/wx/configure --with-osx_cocoa --enable-debug

If you prefer to build in 32 bits, add --enable-macosx_arch=i386 switch to configure. Another useful option is -C to make configure cache the results of its checks, this will make it run much faster the subsequent times. In any case, after doing this you just need to do make -s -j8 with "-s" added to avoid huge quantities of output you probably don't care about and "-j8" being adequate for the modern quad-core CPUs. Of course, if you use a less -- or more -- powerful machine, adjust the "8" accordingly. Depending on your machine characteristics the build can take anywhere from a couple of minutes to half an hour or more but it should eventually finish. To test that everything well, and also because we will need it later for testing anyhow, try building and running the "widgets" sample:


 $ cd ~/build/wx/osx_cocoa-debug/samples/widgets
 $ make -s
 $ open ./widgets.app

Next step is to add stubs for OS X-specific version of the control: usually, the control you want to implement will be already available under OS X but its "generic", i.e. platform-independent and hence not really Mac-looking, version would be used. We want to replace it with the native one so let's do it by modifying a few files in wxWidgets sources:

Modify include/wx/datetimectrl.h to include wx/osx/datetimectrl.h if __WXOSX_COCOA__ is defined. Notice that we only implement this control for the Cocoa port version, if you were doing it for both Carbon and Cocoa, you would have tested for just __WXOSX__.

Our example is actually more complicated than a typical control because there are two classes: wxDateTimePickerCtrlBase, which is the common base class for wxDatePickerCtrl and wxTimePickerCtrl and wxDatePickerCtrl itself. So we also need to update include/wx/datectrl.h in a similar way.

Of course, now that we added inclusions of the new files, we actually need to create them so let's do it. Both headers should declare the corresponding classes, i.e. the same as in the common headers from where we include them but without the "Base" suffix. So let's define wxDateTimePickerCtrl, inheriting from wxDateTimePickerCtrlBase in include/wx/osx/datetimectrl.h. and, similarly, wxDatePickerCtrl inheriting from wxDatePickerCtrlBase in include/wx/osx/datectrl.h. You can copy the file structure (i.e. the standard header comment, the include guards, ...) from another OS X header or maybe from the common header that you already modified itself. Don't forget to put your name in the "Author" line!

Usually, the classes we declared are concrete, so they should have the correct constructors and implement base class pure virtual methods. The "Base" classes don't define the constructors so we need to look at an existing implementation, for example the native MSW one in include/wx/datectrl.h, to see which arguments should the constructor take. You can simply copy the constructors (including the default one) and Create() function declaration from there as they must be the same for all ports, it's just their implementation that will be different.

At this stage, it might be a good idea that our new headers compile correctly (of course, nothing is going to work nor even link yet) so you could try to compile some file including them. In my case let me check if "make advdll_datavcmn.o" still works -- it does, so we didn't make any stupid mistakes (yet) and can continue.

Let's add the stubs for the implementation of the new classes too now:

Create src/osx/datetimectrl_osx.cpp and src/osx/cocoa/datetimectrl.mm. The latter is an "Objective-C++" source file, hence the relatively unusual extension. Again, as we actually are implementing two new classes and not one, we also need to create src/osx/datectrl_osx.cpp. But as we suspect that we won't need any Cocoa-specific implementation for this class (as everything will be done in the base one), we don't need any other Objective-C++ files.

We need to update wxWidgets build system to take the new files into account. For this, we need to edit build/bakefiles/files.bkl, locate ADVANCED_OSX_COCOA_SRC definition in it and add the new files paths to it. Also do the same for ADVANCED_OSX_COCOA_HDR.

If you don't have it yet, you need to install bakefile for the next step. Just grab the DMG from download page and install it as usual.

Go to build/bakefiles subdirectory and run bakefile_gen -b wx.bkl to update all make and project files for wxWidgets.

Finally, re-run configure or just recreate the makefile using the command ~/src/wx/regen Makefile from the build directory.

And redo make again as a sanity check. I got undefined symbol error from the linker about wxDatePickerCtrl::GetClassInfo() when doing this, which made me realize that I forgot to put wxIMPLEMENT_DYNAMIC_CLASS() in src/osx/datectrl_osx.cpp. After adding it, everything linked correctly. Of course, nothing works yet but we're going to change this soon.

So, finally, here is the interesting part: actually implementing the control using Cocoa API. The details of doing this depend on the exact control used, of course, e.g. we are going to base it on NSDatePicker in this case but another subclass of NSControl would need to be used for another control. But some things need to be done for all of them in more or less the same way because all wxOSX classes are similar and use pImpl-idiom: the wxControl-derived class itself just forwards all of its methods to its "peer", which is a pointer to an internal object of a class deriving from wxWidgetImpl implemented differently for Carbon and Cocoa ports. In more details:

As we need some additional methods in our "impl", we're going to define a new class for it. Notice that sometimes this can be avoided as wxWidgetImpl already has quite a few standard methods which are enough for many common controls. In our case, however, they are not. So we add a new include/wx/osx/core/private/datetimectrl.h header and define wxDateTimeWidgetImpl class with the Set/GetDate() and Set/GetDateRange() methods corresponding to wxDatePickerCtrl methods we need to implement in it. Notice that this is a private header, not installed when wxWidgets is installed, so there is no need to add it to build/bakefiles/files.bkl unlike the public headers we had created before.

We also a static CreateDateTimePicker() method that we'll use for creating the native Cocoa control to this class as well.

The implementation will be the same as for the other Cocoa widgets, i.e. it will first create a subclassed NSDatePicker which is only necessary in order to call wxOSXCocoaClassAddWXMethods() (it would definitely be nice to have some way to avoid duplicating this code, even if it's quite trivial for all classes, but I don't know how to do it -- contributions from Cocoa/Objective-C experts would be welcome) and associate it with the peer object mentioned above.

We also need to implement wxDateTimeWidgetImpl implementing all its pure virtual methods we added above and implement them using the corresponding NSDatePicker methods in the straightforward way. We'll call our derived class wxDateTimeWidgetCocoaImpl for consistency with the similar classes.

Finally we also need to add code for generating events for our control. In this case it is very simple as there is only one event and it's the main/default action of the Cocoa control so it's enough to just override controlAction() method in wxDateTimeWidgetCocoaImpl.

By now we have a minimally working implementation of the control! It's definitely not perfect as we don't handle almost any styles of wxDatePickerCtrl, notably wxDP_ALLOWNONE, but as there doesn't seem to be any simple way to implement it with the native Cocoa control we're just going to leave it unimplemented for now. We do need to mention this to warn the users so let's update interface/wx/datectrl.h to add a note about this.
Otherwise no new documentation needs to be written as it already existed so we are almost done.

The last thing is to submit the changes for the inclusion to wxWidgets. This is normally done by submitting a patch to our Trac but as this patch is rather extensive, it's a good idea to request a review for it first. Remember to clean up your patch before submitting for the review, just as I did before submitting this patch.

While this post turned out to be quite long, it's mostly because I tried to describe all the steps, including the very first ones, in details. It also involved a rather atypical case with 2 different classes being involved when usually only one of them is. Adding new controls to wxOSX is really not that difficult and I hope this walk-through will encourage more people to do it. And if you do follow it and find any inexactitudes (this word sounds so much better than "stupid errors"), please let me know and I'll correct them here.

Happy hacking!

* For some values of "unabridged" and "true". I did simplify a few things, mainly because I implemented both wxDatePickerCtrl and wxTimePickerCtrl at the same time.

2.9.3 release in details

2011-12-14T16:21:00.001Z

wxWidgets 2.9.3 has been officially released today. In spite of our efforts to speed up the release process, it still took us 5 months to do it after 2.9.2. However it's significantly better than a year that both 2.9.1 and 2.9.2 had taken. And we plan to make 2.9.4 sooner than in 5 months too as explained in the updated roadmap.

As a remainder, here is a summary of the most important new features that appeared in wxWidgets since 2.9.2:

The star addition of this release is the wxWebView library by Steven Lamerton and Auria, developed during Google Summer of Code 2011. It is by far the biggest and most important new feature. Thanks to it it is finally possible to embed a fully functional native web rendering engine (with JavaScript and CSS support) in wxWidgets applications.

wxTimePickerCtrl logically complements wxDatePickerCtrl. Currently it uses a native control under MSW and a generic implementation elsewhere but we have plans to also provide a native implementation for OS X in the next version (and for wxDatePickerCtrl as well).

wxTreeListCtrl: this is much less revolutionary but is a convenient and, most importantly, simple to use multi-column hierarchical control.

wxRichToolTip and wxBannerWindow are also not exactly earth shattering but provide a simple way to enhance your application UI by presenting more information in a nice and not distracting way to the user.

Time functions now can return time with microsecond, rather than millisecond, precision and wxStopWatch is more precise thanks to this.

The generation of wxEVT_CHAR_HOOK event was made consistent for all the major platforms and DoAllowNextEvent() was added to make it possible to handle this event in more flexible way.

wxMessageDialog gained support for wxHELP button and, consequently, it is now possible to easily show message boxes with up to 4 (instead of 3 before) custom buttons. We are sure that wxWidgets users won't abuse this feature but, just in case, we officially announce that 4 is as high as the number of message box buttons will ever go.

You can now try to enter a critical section, without blocking.

wxTextCtrl has gained support for auto-completing the directories (unfortunately, as with the files, this is only implemented in wxMSW currently).

And it is now also possible to find the pixel coordinates of a text position in wxTextCtrl which is helpful for e.g. showing a context menu or a popup window for the given character or word.

Support for wxSplitterWindow persistency was added, meaning that you can now simply call wxPersistentRegisterAndRestore(splitter) to automatically save the splitter position and restore it the next time your program is executed. Additionally, the location and the format of saved persistent options can now be customized by providing a custom wxPersistenceManager and overriding its GetKey() method.

Keyboard navigation in generic wxDataViewCtrl has been significantly enhanced to make it really practical to use it for editing and not just browsing data.

There were many more minor additions and plenty of bug fixes as well, of course, see the change log for even more details.

Finally some combined statistics about the changes since the last release:

% git shortlog -sn remotes/tags/WX_2_9_2..
   465  Vadim Zeitlin
   232  Steven Lamerton
    74  Stefan Csomor
    71  Vaclav Slavik
    47  Dimitri Schoolwerth
    47  Robin Dunn
    41  Paul Cornett
    26  Julian Smart
    21  Jouk Jansen
     6  Francesco Montorsi
     5  Chris Elliott
     1  Bryan Petty
     1  John Chain
     1  Mike Wetherell

for 1038 commits. Notice that my own check ins include committing many patches from other people (which git would have kept track of but svn is unfortunately incapable of this). In particular, I'd like to thank Catalin Raceanu, Kinaou Hervé, David Hart, troelsk, Armel Asselin, wsu, joostn, Navaneeth, Allonii, ivan_14_32, Marcin Wojdyr, John Roberts and others for their contributions to this release (sorry in advance if I forgot anybody in this list, please contact me if you should have been included into it). To keep an idea of the amount of code changed by these commits here is another statistics:

% git diff --shortstat remotes/tags/WX_2_9_2
 1202 files changed, 231492 insertions(+), 149751 deletions(-)

So around 80000 lines have been added which seems enormous but more than 60000 of them were actually changes to the (automatically generated) make and project files and message catalogs so "only" approximatively 18000 new lines of code have been added. Remarkably, almost 6000 of them were added to the documentation and another 1500 or so to the unit tests. On the other hand, we actually lost 20000 lines in an upgrade of libpng so the actual amount of the new lines in our own code is close to 15000 which is still pretty impressive.

On a less bright note we also have:

% ./trac-ticket-stats trac.wxwidgets.org 2011-07-04 today
Ticket statistics for http://trac.wxwidgets.org/timeline from 2011-07-04 to 2011-12-14:
--------------------
New              454
Closed           397
Reopened          59
--------------------
Delta            116

so while almost 400 bugs were fixed since 2.9.2, net effect is unfortunately that today we have 116 more bugs than 5 months ago.

Please help with testing 2.9.3 RC

2011-12-02T20:14:00.002Z

Release candidate for the next 2.9.3 is available from SourceForge and soon will also be at FTP mirror.

Please test the distribution files and let us know about any problems you encounter with downloading, compiling or installing from them. If all goes well the final 2.9.3 should be done next week.

Thanks in advance for your help!

August Augmentations

2011-09-03T15:14:00.000Z

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.

Cleaning patches for the review

2011-08-20T12:03:00.002Z

Unfortunately (and, as usual, for historical reasons) we keep quite a few auto-generated files in wxWidgets sources repository, for example configure (created by autoconf), a lot of setup.h files all generated from the master setup_inc.h template using a simple sed script and also tons of makefiles (created by bakefile).

One of the many reasons this is inconvenient is that changes to these files get in the way when reviewing patches. But luckily, it's simple enough to fix this, at least if you're using a Unix system with patchutils on it. It's enough to execute this command:



filterdiff -x '*/*.vcproj' -x '*/*.dsp' -x configure -x \

'*/makefile.*' -x '*Makefile.in' -x setup.h.in \

-x include/wx/msw/wince/setup.h -x '*/setup0.h' \

some-wx-patch.diff > some-wx-patch-clean.diff

The command is actually not difficult to write but it is long and it's easy to forget something (as I just did for not the first time when retyping it) so I recorded it in a one-line script called clean_patch and now you (and I) can simply do



./misc/scripts/clean_patch some-wx-patch.diff > some-wx-patch-clean.diff

instead.

If you add any new files, any new wxUSE_XXX constants or modify configure.in, please remember to clean your patches up. The clean patches are much more pleasant to review and easier to merge, even if there were other changes to the auto-generated files in the meanwhile.

Another Victory in the War Against Macros

2011-07-28T22:01:00.001Z

wxWidgets is notorious for using many macros. While evils of macros in C++ are well-known, sometimes they are really necessary, e.g. wxIMPLEMENT_APP hides the difference between using main() or WinMain() as entry point and sometimes, even if there are alternative approaches not involving macros, e.g. using a base class instead of wxDECLARE_NO_COPY_CLASS macro, their use is still not particularly offending. In still other cases macros are used to provide a kind of a DSL, such as event table macros that allow to describe event handler connections statically and less flexibly but more concisely than Connect().

However in some cases there is really nothing that can be said in defense of
using the macros and they are present in the code just for "historical
reasons", i.e. because nobody thought about doing it better back when the code was first written, often enough almost 20 years ago. We try to deprecate (which is a polite term for "get rid of") such macros progressively and there are not that many of them left, at least on the interface side.

A couple of days ago I finally managed to ditch a particularly aggravating set of them: the so-called "control container" macros. They must be used in the classes that represent windows containing other windows ("controls") in order to allow TAB navigation inside them. While wxPanel and wxDialog, which are two of the usual control containers, already do it, you had to explicitly use macros such as WX_DECLARE_CONTROL_CONTAINER() and WX_DELEGATE_TO_CONTROL_CONTAINER() if you wanted to write your own composite controls. Luckily few people did this because these macros were not even documented but even just using them in wxWidgets itself causes much teeth gnashing. And particularly so from my part, almost surely because I wrote these macros myself (and only 10 years ago so even the "explanation for using macros here is forever lost in the mists of time" excuse is at most half-valid).

So when I had to add correct keyboard navigation to wxSearchCtrl to fix another bug, I finally decided to atone for my mistake. The solution turned out to be surprisingly simple and nice: instead of all these macros I added a new wxNavigationEnabled class which uses CRTP to inject the TAB-handling logic into the derived class. So, as the example in the documentation shows, you now simply have to inherit your custom composite control from wxNavigationEnabled<wxWindow> instead of directly deriving from wxWindow to get correct keyboard handling, e.g.:

class MyCompositeControl : wxNavigationEnabled {
    ...
};

Using wxNavigationEnabled is definitely much simpler than using macros -- in fact, it's so simple that it could even finally be documented quite painlessly, which is a good criteria -- so I'm quite happy with it (as you can see, even happy enough to write a blog post about this). Even though not having to do anything at all and have TAB-navigation just work would certainly be even better, this can't be done without moving all the TAB navigation logic down into wxWindow itself and there are many, many windows which don't contain any other controls this doesn't look like a good idea.

Anyhow, this battle against macros was won but the war is not over yet. Getting rid of (or at least providing non preprocessor-based alternatives to) all macros in wxWidgets is not the highest priority issue but it's still nice to make some progress on it. And if you have any candidates for irritating macros to be dealt with next, please let us know!

Less flattering statistics

2011-07-24T17:12:00.002Z

I've stopped counting the number of opened and fixed Trac bugs quite some time ago because it was too much trouble to do it semi-manually. But one of the side effects of the recrudescence of my love affair with Perl is that I'm looking for excuses to write more Perl code and so I spent half an hour today on writing a small script allowing to gather ticket statistics automatically. This is probably not the best way to do it (it would be better to install some Trac statistics plugin server-side) and the script itself is pretty trivial so it didn't quench my quest for more Perl neither but at least it does quickly give the statistics I wanted.

The bad part is that I didn't want the statistics I got because it in spite of all our efforts the number of opened bugs in wxWidgets keeps increasing. The only good news is that the rate of increase seems to have decreased or at least stabilized: if in 2009 we had 271 new bugs (computed as the difference between 1270 opened and 145 reopened ones and 1144 closed ones), in 2010 we had "only" 275 new bugs and so far in 2011 we have only 20 news ones (and it's not as people got simply tired of reporting them, there were still 521 newly opened bugs since the beginning of the year). But in all, we still have 544 more bugs today than in May 2008 when Trac statistics begin so the journey towards bug-free future remains long...

Out of curiosity I also collected the month statistics using the following intimidating command combining the wonders of zsh short loop syntax and GNU date relative dates support:


% for ((year=2008;$year<=2011;year++)); \
  for ((i=1;$i<=12;i++)); \
  ./trac-ticket-stats --csv trac.wxwidgets.org $year-$i-01 \
    `date --date="1 day ago 1 month $year-$i-01" +%F`

and discovered somewhat surprising variations between the months: on average, we get 60 net new tickets per month but there are some outliers. In Januaries there are almost no new bugs (2) while in October there are 112 of them. Looking at the number of bugs created, more bugs are created in March, October and July (which are very close) while wxWidgets users seem to be on vacation in June when almost twice less bugs are opened. As for us, the developers, we seem to start every new year with good resolutions as January is the month with by far the most bug fixes while by June working on them really loses its appeal and two times fewer of them are resolved.

Self flattering statistics

2011-07-15T21:50:00.004Z

After receiving the latest monthly Source Forge newsletter with their list of top 25 projects I became curious because at first glance it had seemed like most of them were Web-based applications and I wondered if it really was so. So I spent 10 minutes clicking on all the 25 links and quickly looking at the programming languages/environments/frameworks these projects used and here is what I found (please bear in mind that I could easily make some errors, all this is very quick and rough):

http://www.phpmyadmin.net/: Web/PHP

http://adempiere.sourceforge.net/: Java

http://www.zkoss.org/: Java

http://arianne.sf.net/: Java

http://www.finkproject.org/: Perl(?)

http://portableapps.com/: Python

http://mediainfo.sourceforge.net/: C++/wx (and Qt?)

http://jmri.sourceforge.net/: Java

http://www.net-snmp.org/: C

http://www.scummvm.org/: C++

http://www.taskcoach.org/: Python/wx

http://www.xoops.org/: Web/PHP

http://squirrelmail.org/: Web/PHP

http://postbooks.sourceforge.net/: C++/Qt

http://www.openbravo.com/: Java

http://ffdshow-tryout.sourceforge.net/: C

http://www.freedos.org/: C

http://pwsafe.org/: C++/wx

http://getgreenshot.org/: C#

http://www.omegat.org/: Java

http://tuxpaint.org/: C/SDL

http://www.dvdstyler.org/: C++/wx

http://keepass.info/: C++/MFC

http://www.dvtk.org/: C++ (?)

http://www.scintilla.org/: C++

As you can see, actually my initial impression was totally wrong and there are only 3 web-based applications (incidentally, all written in PHP) whereas there are twice as many written in Java. What really surprised me, however, was that 4 of them used wxWidgets (although I'm not sure if it's the main UI used by MediaInfo as it also seems to use Qt). I knew about DVDStyler but not the other ones so it was a pleasant surprise.

Of course, I have no idea what are the exact criteria for choosing these 25 "top" projects and there are plenty of Open Source projects not hosted on SourceForge, without even speaking about all the other ones, and so on but, still, it seems like wxWidgets is more popular than I thought (and otherwise I wouldn't have written this post, would I?).

2.9.2 and plans for the future

2011-07-08T07:51:00.003Z

As you've probably noticed at www.wxwidgets.org, the new 2.9.2 release was finally officially released this Tuesday. I won't detail its new features in details here as most important of them were already covered before but just wanted to say a few words about our future plans.

The next release -- incredibly enough -- will be 2.9.3 and we plan to do it at the end of September, after merging the work of GSoC 2011 students in the trunk. So ideally this release will have GTK+ 3 support, a new wxiOS port, wxWebViewCtrl for embedding a "true" HTML rendering engine (such as Trident under MSW or Webkit elsewhere) and a new UI animation library. Being realistic (although I'd certainly like to be proven wrong!), at least some of these things will probably be delayed but the release itself should still happen.

Depending on the things included in or omitted from 2.9.3 we may need to do 2.9.4 with all the big features we want in 3.0 next, although I'd like to avoid it and, again, ideally, 2.9.3 would already have all of them. If 2.9.3 does have everything and if no huge problems are discovered in it, we'd like to release 3.0 before the end of the year (meaning not later than mi-December). But then again, you have to be realistic about these things, so 3.0 will probably happen in the beginning of the next year rather than in this one. Still, planning it for 2011 at least gives us a target to miss.

As usual, let me end any roadmap discussion with a plea for help: we need your help. Most obviously with testing the huge amounts of the new code that will hopefully be in 2.9.3. But also with wxOS port as Stefan is almost alone working on it and with GTK+ 3 stuff as few people know it (yet). Please help us make 3.0 available sooner and, most importantly, better -- thanks in advance!

Choosing gcc for building wxWidgets under Windows

2011-06-18T14:57:00.004Z

There are a lot of possibilities for building wxWidgets under Windows using gcc. First of all, you can choose to use traditional makefile in build/msw/makefile.gcc. This binds you to using a MinGW version of the compiler in Windows command prompt (i.e. cmd.exe as hopefully nobody uses systems with command.com any more) as the makefiles use DOS/Windows style paths and commands. Second, you can use the traditional Unix configure-and-make approach. Then you have a subchoice between using MSYS which is a minimalistic environment developed by MinGW project or a full-blown Cygwin one. In the former case you would use MinGW compilers too, of course, and in the latter one the natural idea is to use Cygwin compilers. This however means that the generated programs would depend on Cygwin DLL and would require installing it for them to run. As this can be undesirable, there is also a possibility of using a MinGW cross-compiler from Cygwin environment which combines the advantages of being able to use Cygwin on the build machine while not requiring anything special for the deployment.

Let's summarize the choices in a concise list:

Use makefiles: implies the use of MinGW compiler in DOS prompt.
Use configure+make; then choose between

Using MSYS and MinGW compiler
Using Cygwin and Cygwin compiler
Using Cygwin and MinGW cross-compiler

The choice (1a) is probably the simplest one if you want to install as few things as possible. However, it doesn't allow you to easily specify many compilation options (you need to edit setup.h file instead of just passing options to configure on command line) and, worse, it doesn't produce a wx-config script as part of the build -- and even if it did, there would be no way to use it without some kind of Unix-like shell.

Because of this, I always recommended using the second approach to building wxWidgets. Moreover, personally I've always favoured using Cygwin because I use zsh all day long anyhow. However traditionally you had to use Cygwin compiler which was the worst of the lot. Not only did it always lag a version or two (and sometimes more) behind the latest available MinGW one, but it also was significantly slower than MinGW version. And, of course, the binaries created by it depended on cygwin1.dll. Because of this, people fond of Cygwin (or, alternatively, not fond of many MSYS problems), also tried to use native MinGW compilers under Cygwin and this could be made to work but was so painful because you had to painstakingly ensure that both MinGW compiler and Cygwin tools could understand the paths you used (which basically meant that only relative paths could be really used as absolute paths take different forms for Windows-based MinGW compiler and Cygwin-based tools) that I could never wholeheartedly recommend it.

So I was very pleasantly surprised when I learnt that Cygwin now provides recent versions of MinGW cross-compiler or, rather, several of them. As Charles Wilson explains here, there is a cross-compiler for Win64 from MinGW64 project, another cross-compiler for Win32 from the same project and also a Win32 cross-compiler from "traditional" MinGW. Hence now you have yet another choice to make in case (2c).

Obviously, if you need to target Win64 the choice is easy to make, as there is only one of them. I recommend using MinGW64 version of Win32 cross-compiler as well for two reasons: first, it seems quite likely that you will need to target Win64 later even if you don't need it now, so why not the same compiler that would allow you to build for Win64 later. And second, MinGW64 uses the so-called SJLJ exceptions which can propagate through the code not compiled with gcc, e.g. all Windows system DLLs. And in practice this is needed to be able to catch any exceptions thrown by your wxWidgets event handlers. So while DW2 exceptions uses by MinGW version do have their advantages (in particular they are much more speed-efficient), SJLJ ones are preferable for wxWidgets GUI applications.

To summarize, my recommendation for building wxWidgets under Windows using gcc is now straightforward and unambiguous: use MinGW64 compiler under Cygwin. To be more precise, you need to install Cygwin (if you don't have it yet) and its mingw64-i686-gcc-g++ package (you shouldn't download this file directly though, use Cygwin setup program to install it with all its dependencies). Then you simply need to run wxWidgets configure with the following options:


$ /path/to/wx/configure --host=i686-w64-mingw32 --build=i686-pc-cygwin ...

and run make as usual. You can also use wx-config script and, in general, things are almost as nice as under Unix. Just don't forget to use i686-w64-mingw32-g++ compiler instead of plain g++ if you write it manually instead of using `wx-config --cxx` output.

Another good news is that the speed of the compiler seems to have improved dramatically since the bad old gcc3 days: building the entire wxWidgets takes less than 4 minutes here with make -j8 in default shared library build. Running configure itself is still painfully slow the first time but reasonably fast afterwards if you use -C option to cache the tests results.

Good luck building your applications using wxWidgets using Cygwin cross-compilers and thanks for Cygwin and MinGW(64) folks for making it faster and easier than ever!

Using dynamic auto-completion in text controls

2011-04-18T23:06:00.002Z

wxTextEntry supports auto-completion of a fixed of strings in wxWidgets 2.9 since quite some time however so far you had to specify the full of set of strings to complete and, incidentally, this didn't work under OS X meaning that one of three major platforms didn't support auto-completion at all.

Lack of support of OS X aside, this is a useful feature which helps the users a lot with the data entry. For example, it is typically used to keep the history of previous entries in a text control and auto-complete the entries used in the past automatically. And for this the existing AutoComplete() worked fine. Sometimes, however, using a fixed set of strings is impractical. A typical example is trying to complete the results of some database queries: there can be a lot of them and it can be wasteful to get all the results from the database. It would be much better to be able to dynamically retrieve just the completions for the prefix already entered by user.

And this is exactly what the newly added wxTextCompleter class and wxTextEntry::AutoComplete() overload taking it allows to do. A text completer object can dynamically generate the completions using the prefix already by the user, either by overriding Start() and GetNext() methods of wxTextCompleter itself or by overriding the single GetCompletions() method of wxTextCompleterSimple class. The widgets sample was updated to show how to do it and the documentation of wxTextCompleterSimple also contains a simple example and hopefully the new API should be clear enough to be used without problems.

As usual, things could be improved further: for one, even though the new dynamic auto-completion is implemented under MSW and OS X, it is not implemented under GTK yet. It shouldn't be difficult to do it by defining a GtkTreeModel forwarding to wxTextCompleter and using it with GtkEntryCompletion but this still remains to be done. Also, under OS X the completion currently needs to be triggered manually by pressing F5 and doesn't appear automatically. This is the native behaviour but it doesn't seem to be particularly useful so we'd need to make it appear automatically. As usual, any contributions implementing either of those improvements would be gratefully received by wxWidgets project so don't hesitate to help if you'd like to use the missing features in your programs.

But even in the current state, you can easily define custom dynamic text completers and also use fixed lists of completion strings under all of the major platforms now.

Help with attracting students for GSoC 2011

2011-04-06T12:38:00.003Z

This year we have surprisingly few proposals from the students willing to work on wxWidgets during this year Google Summer of Code. All the previous times when we participated in the GSoC we had more proposals than the slots allocated to wxWidgets but this year it looks like the reverse might happen for the very first time as two days before the proposal submission deadline we only have two worthy proposals and a couple more of more or less junk ones while, for comparison, the last year we had 7 or 8 interesting proposals and 5-6 or more of lesser quality but still not quite worthless.

And as we always had enough good proposals to take all the slots we were assigned, we never really did much advertisement for it. However this year it looks like it was a bad mistake to not do it so, considering that later is still better than never (even if it's really very late -- again, there are only 2 days left before the deadline), I'd like to ask for the help of the readers of this blog with spreading the word about SGoC in general and wxWidgets participation in it in particular among any students (and maybe also professors) you might know.

Personally I'm convinced that for any student interested in working on a real life yet fun and interesting project during the summer vacation, learning both more about the technical subject and also about how to work in an open source community in general and, moreover, be paid on successful completion of the project, participating in GSoC is really a great opportunity -- so please let know anybody who might be concerned about it.

Thanks in advance!

Markup in control labels

2011-02-22T18:12:00.007Z

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.

Do Androids dream of wxWidgets?

2010-12-07T23:23:00.003Z

Don't know about androids to be honest but I'd definitely love to be able to develop applications using wxWidgets that could run on both iPhone (which is already kind of possible) and Android and also reuse at least parts of their code with desktop versions. Unfortunately Android doesn't exactly encourage developing in C++ but things seem to be slowly moving in the right direction and the last NDK release allows to implement GUI applications entirely in C++ by providing the new NativeActivity class.

There is still no convenient access to native widgets but we can use Java classes from C++ code via JNI and we could even automatically wrap them using something like JCC. So at least in principle it seems that there are no obstacles to implementing a working wxAndroid port. And at least wxUniversal could be ported without using JNI at all and just using OpenGL for drawing.

All we need right now are the volunteers (and/or donations...) to make it happen. For me personally it would be one of the most interesting things to do after releasing wxWidgets 3.0.

GSoC 2010 Mid Term

2010-07-22T13:00:00.003Z

Even though it was expected because we could see all of them working hard, I'm still happy to announce that all GSoC students working on wxWidgets this summer have passed their mid term evaluations with flying colours, congratulations! To give you some insight in what exactly has happened during the first half of the program, here are progress reports straight from the students themselves:

wxRichTextCtrl image support improvements project

Mingquan Yang

My project generally contains two main parts: an image controlling dialog and multiple image floating supports.

For controlling dailog, in the past weeks, a new class wxRichTextImageDlg was added to control the image properties.
And wxRichTextImageAttr is completed to pass the image property between image object and controlling dialog. Now the dialog supports image alignment, floating and image scaling change. And in layout, we only support image scaling now. The richtext sample application is changed to add the new feature.

The floating layout work started from last week and get a detail discuss about how to anchor an image to a paragraph and how the alignment/floating affect the image with my mentor. Now, code design is complete and I have started coding on this floating algorithm.

Implementing support for new Windows Vista/7 UI elements in wxWidgets

Rickard Westerlund

My work started out slow with school ending late and other issues I've had to deal with. It's going quite well now, I've finished my work on implementing wxCommandLinkButton and I should be finished with task dialog replacement for wxMessageDialog as well as the new wxRichMessageDialog pretty soon. I hope I will also be under way with the task dialog replacement for wxProgressDialog at the time of the mid-term evaluation.

Most of the problems I've encountered have been related to following the code structure and style of wxWidgets, since I haven't worked with it before. Since I've learnt a lot about that I believe the work on the remaining components to go much smoother.

For the next period I will work on implementing a wxSplitButton class and a native implementation of wxHyperLinkCtrl using syslinks for Windows. I've already looked into split buttons and syslinks and come up with some ideas for the implementation.
Finally, for the taskbar-related functionality I had planned I'd like to at least implement the progress bar as it should be possible to implement under other platforms as well.

Masked edit control implementation

Julien Weinzorn

In the beginning, my work was to write documentation and the base of the classes wxMaskedField and wxMaskedEdit. Next I have created unitary test and correct my code.

After this I got some problems with autoconf and event connection, but now it works well. Therefore my timeline was ambitious and the project is a bit more complicated than I thought.

Two weeks ago I have beginning to write a basic sample to test my code and it was not working according to wxPython. Therefore I have test an other way to code maskEdit and the new version works find with single field mask.

At present, wxMaskedField and wxMaskedEdit are completed. I think the docs is for a great part written. Unitary test are write and all test works. The connection between textCtrl and mask works. The connection between comboBox and mask works.

Now I want to add mouse support, and next add sample withing multiple field and default user input (it is an array of possible choice). Next add some advance features like change fill char, add some formatCode to change the mask behaviour and if I have the time, attempt to a regex validation options.

wxQt port

Javier Torres

wxQt is progressing well. I have already implemented wxDC and friends so we can paint on windows and bitmaps. Also, I have started
implementing the window functionality I needed to be able to test the image and drawing samples. Right now, both the drawing and images sample compile and work fine (although some functionality such as blitting is still not there). Some random screenshots comparing side to side with wxGTK (up and left is qt, down and right is gtk):
first and second one.

On the wxWindow front, the event handling architecture is there, and some random events are handled (mousewheeling, OnPaint and some more) and implementing all of these is the next objective. After that, the only thing missing to complete the initial idea for the project is all the details of windows and subclasses (mostly the scrolled window as it is the most different).

Unit tests for the GUI features

Steven Lamerton

GUI unit-testing work is coming along nicely, especially as my exams didn't finish until just before two weeks ago. Before my exams (and during them too!) I worked on wxUIActionSimulator. The keyboard related functions now all take a wxKeyCode rather than platform specific key codes and wxKeyModifiers rather than a long list of bools. The Unix implementation specifically was nearly completely re-written and a wxKeycode -> CGKeyCode function was written for OSX. I now feel wxUIActionSimulator could be enabled by default rather than disabled.

Since exams I have been working entirely on testing. I have written a new wxTestableFrame class for counting events and updated the existing unit-testing framework to make use of it. Once this was completed, and the issue I brought up on the list was solved, I started working on new test cases. In just over a week I have increased the number of tests from roughly 85 to 160. Many of these are testing the events generated by controls and ensuring they actually match up to the documentation.

Thanks once again for all of you and good luck for the rest of the program!

2.9.1 Finally Done

2010-07-19T09:00:00.001Z

The 2.9.1 is finally officially done, all the files are here or at the FTP mirror. Not much to add to the previous posts about 2.9.1, I can only say that for me this is without doubt the best^* wxWidgets release to date and it's incredibly more convenient and practical to use for development than 2.8.

Thanks to Stefan for quickly fixing the two important Mac bugs mentioned in the last update. And thanks for Source Forge for making the releases much, much less painful than in the past -- you can now simply scp the files to their file release system instead of passing by the hideous and incredibly slow (at least in the past when I had to use it) web-based file manager. It's a pleasure to see such outbreaks of common sense, even if (or "especially when"?) they come after years of torturing people with their old interface.

And, of course, thanks to everybody else who contributed to this release and the ongoing wxWidgets development. You're too numerous to be listed here but your help is really appreciated and, as hard as it could be to believe, the release would have taken even longer (if it ever happened at all) without it. Thank you!

* Barring some catastrophic bug which we didn't notice, of course...

2.9.1 Update

2010-07-15T10:23:00.002Z

Unfortunately some new bugs prevented us from making 2.9.1 as planned and now we aim at July 19 instead. Please let us know if you find any other important problems in the current svn!

Preparing for 2.9.1

2010-06-21T12:25:00.002Z

Sorry for lack of posts summarizing the recent wxWidgets development progress and here, to compensate, is a post about an upcoming development: we're finally going to release 2.9.1 soon. This release will include many of the things previously discussed here, notably new debug build handling, thread-safe wxLog, new wxInfoBar class and so on.

It will also probably be the penultimate release before 3.0 as the current thinking is to release 2.9.2 after merging the work of the students on GSoC projects this summer some time in September and then follow with a 3.0 release before the end of the year. So testing and finding bugs and, even worse, regressions compared to the old 2.8 versions would be very welcome.

The schedule for this one is to make a release candidate before the end of this week and the final one on July 12 or, if any important problems are found with the RC, on July 19 to give us some time to ~~hide them under the carpet~~ fix them.

GSoC 2010 Projects Announced

2010-04-30T10:54:00.002Z

We're very happy to announce that five students have been accepted by Google Summer of Code program to work on wxWidgets this summer. Our congratulations to:

Mingquan Yang who will enhance images support in wxRichTextCtrl.
Rickard Westerlund who will bring support to new Windows Vista/7 UI elements to wxWidgets.
Julien Weinzorn who will implement the masked edit control.
Javier Torres who will work on wxQt port implementation.
Steven Lamerton who will add many more unit tests for wxWidgets GUI classes.

(if you're wondering about the order, it's really random -- or, rather, reversed (because using the straight one all the time is not fair, especially if your name starts with 'Z' :-) alphabetical order of names).

The projects are a mix of concrete, immediately user-visible improvements and more ambitious long-term investments. But all of them should be very useful to wxWidgets and its users.

Thanks once again to Google for organizing the Summer of Code and looking forward to it!

Better display of wxTypes in MSVS debugger

2009-12-22T15:56:00.003Z

This is a quick note about displaying a few wx types in MSVS (2003 and later) debugger as I just discovered, to some surprise, that some people using wx don't know about it. Let me show what I mean with an example: I have the following in my %VSINSTALLDIR%\Common7\Packages\Debugger\autoexp.dat:


[AutoExpand]
... all the existing stuff ...
; wxWidgets types
wxPoint=<x>,<y>
wxSize=<x>*<y>
wxRect=<x>,<y> <width>*<height>

wxDateTime=<m_time.m_ll>ms
wxLongLong=<m_ll>
wxString=<m_impl>

This allows to see the contents of the variables of the types above in a much better way than the default display (e.g. by default tooltips for wxRects only show x, y and width values but the height is truncated -- hardly convenient). I wonder if others have more types to add to this list?

Of course, there are limits to this approach. For example, I'd really prefer to see an ISO 8601 representation of wxDateTime instead of the number of milliseconds since the Unix Epoch which is currently shown. But this probably requires writing a custom visualizer which is a bit more difficult (would anyone have done this already by chance?).

Still, debugging is much nicer when previewing wxStrings is as simple as hovering a mouse over them so if you don't have the above in your autoexp.dat you should really add it there. Just remember that wxString expansion is for 2.9, if you are using 2.8 you need to use <m_pchData,s> instead.

Buzzwords Benchmarking

2009-12-10T16:08:00.007Z

First, a word of warning: this post is not really about wxWidgets at all but I thought that my experience could be interesting for people doing cross-platform development and so might overlap with the interests of this blog readers.

The experience in question was the recent upgrade of my main Windows development machine. I need to develop for Windows but, at least in principle, it doesn't mean that I need to run it as my main OS -- personally I'm feeling more comfortable under traditional Unix-ish desktop environments rather than in Windows UI (as an aside, ever since OS X acquired virtual desktops support I hoped Microsoft would add it to Windows too, but apparently they don't copy the useful OS X features...). However traditionally I did use Windows (Windows 3.1 at the dawn of time, then NT 4.0 for more than 6 years and later Windows Server 2003 for about 5) just because using Microsoft Visual Studio is much more productive than cross-compiling from Linux, especially because of incomparably better debugging support. Nevertheless I always hoped to be able to switch to using Windows in a virtual machine under some Unix-like OS and this is what I tried to do with the latest hardware upgrade. The main question was, of course, how much slower would building software inside of a VM be compared to doing it natively -- so "virtualization" is the first of two buzzwords of the title that I wanted to benchmark.

The second one is "SSD". I've heard so much of how it's the greatest thing since the invention of computer from everybody starting from Anand Lal Shimpi to Linus Torvalds that I couldn't prevent myself from spending a good part of the new box price on a pitifully small (160GB) but hardly inexpensive Intel 2nd generation ("PostVille") X25-M SSD drive. And, of course, I was curious to know if this was money well spent for what matters to me -- that is, compiling/linking speed.

So I did some benchmarks on the new machine. They were perhaps not very thorough, e.g. I didn't reformat the drive after each run, however the variation remained small (1-2 seconds for the tests of physical systems) and the results were consistent so they still seem significant enough to me. The main caveat is that they clearly only make sense for this particular hardware configuration, it could be perfectly possible that using faster and/or more CPU(s) would change the balance. But I didn't have the possibility to test with anything else than this system, with its i7 860 CPU and 8GB of DDR-3 RAM (FWIW I also played a bit with RAM timings to see if this could change anything but they're absolutely insignificant in real-life benchmarks). The system also has 2 1TB Samsung F3 SATA drives which were used as baseline for SSD results (without RAID).

First of all, I compared the times for building wxWidgets under Linux. Here are some results under Ubuntu 9.10 (using g++ 4.4) and Debian Testing (using g++ 4.3):

What	OS	Disk/FS	Time (sec)
configure	Ubuntu	HD/ext4	15
configure	Ubuntu	SSD/ext4	15
configure	Ubuntu	tmpfs	15
make -j4	Ubuntu	HD/ext4	91
make -j4	Ubuntu	SSD/ext4	90
make -j8	Ubuntu	HD/ext4	73
make -j8	Ubuntu	SSD/ext4	70
make -j8	Debian	HD/ext3	66
make -j8	Debian	HD/ext2	63
make -j8	Debian	SSD/ext3	64
make -j8	Debian	HD/ext4	63
make -j8	Debian	tmpfs	59
make -C samples/widgets	Any	any	13

The first results seem to be obvious: SSD hardly presents any advantages in this test. I was rather surprised by this as I thought that compilation and especially linking was a disk-intensive activity. However it turns out that I was completely wrong and that in at least this hardware configuration it's almost entirely CPU-bound. This can be seen by noticing that even using tmpfs (which is clearly the most efficient disk you can use, provided there is enough of free RAM -- as was the case here) results in less than 10% gain. Also note that under Ubuntu there is no difference at all between HD and SSD when using 4 CPUs but a small difference in favour of SSD appears when 8 of them are used. This gives me some hope that maybe SSD can be useful with e.g. upcoming 6-core (and hence 12 logical CPUs taking hyper-threading into account) Intel processors. Or, even now, by using 2 or more Xeons instead of a single i7.

Next I installed Windows 7 (64 bit edition) and beta 2 of MSVS 2010. I won't give the benchmarking results for g++ under Windows as it's catastrophically slow compared to MSVC. Running configure alone took 100 seconds and building (with -j8) took more than 200. Instead I'll give some benchmarks for nmake (which doesn't support parallel builds) and msbuild (which can be used for building MSVS projects in 2010), both under the native Windows 7 installation and in the same installation (or at least produced using the same unattended setup file) in a virtual machine with 4GB of RAM and 4 CPUs under VMWare Workstation 7:

What	OS	Disk	Time (sec)
nmake	Native	HD	134
nmake	Native	SSD	132
nmake (x64)	Native	HD	162
msbuild /m:8	Native	HD	32
msbuild /m:4	Native	HD	34
msbuild /m:8	Native	SSD	31
nmake	VM7/Linux	Any	251
msbuild /m:2	VM7/Linux	SSD	99
msbuild /m:4	VM7/Linux	SSD	57
msbuild /m:4	VM7/Win7	SSD	67

There are two conclusions which can be made from the first half (under native installation of Windows 7). First, and the most important one for me, is that there is once again no difference between using HD and SSD to speak of. Second, amazingly, x64 builds are 20% slower than x86 ones. I don't know if it's due to x64 not being as optimized as the x86 one or just because x64 binaries are larger (by around the same 20%) and so take more time to generate.

The most interesting question however was if Linux could be used for developing under Windows efficiently. Unfortunately the numbers are not good. The best case is slowdown of almost 100% and I discarded the initial timings for the builds inside a VM: for some reason they take markedly longer time then the subsequent ones (10-15 seconds longer, both under Linux and Windows hosts). I don't know why exactly does this happen but it doesn't even really matter as even with the best results I still don't cherish the idea of spending twice as long waiting for the compile to finish. Of course, extra 20 seconds in case of wxWidgets build is not long at all but some of the other projects I'm working on take much longer to build and wait an extra half an hour is a big difference.

Notice that VMware Workstation only allows to use 4 CPUs (and not 8). I thought that the performance might be better if all CPUs were usable and so also tried 2 other virtualization solutions: KVM and VirtualBox. To kill any suspense, they were very far from working better than VMware. I didn't even benchmark KVM because I simply couldn't import my existing VM into it and spending time to reinstall MSVS 2010 in it just didn't seem to be worth the trouble because it felt sluggish enough interactively (probably because due to lack of any equivalent to VMware tools or VBox guest additions?) to not make me want to use it for longer than 5 minutes anyhow. KVM is also clearly very raw, I ran into (admittedly Debian-specific, but still) bugs while installing it and generally it just doesn't seem like something that is meant to work out of the box for interactive use right now.

VBox is another matter: it installed without any problems, imported my existing VM (after conversion to QCOW2 format) and allowed me to configure it with 8 CPUs. It also was perfectly usable interactively after I uninstalled VMware tools and installed the guest additions. All in all, it's a great way to use Windows under Linux... occasionally. Because the performance is just incredibly poor. I don't know if it's something SMP-related and I hope that this might improve in the next versions of VirtualBox (I used the last one available now, 3.1.0) but right now it's not even funny, just look at the numbers:

What	OS	Disk	Time (sec)
nmake	VBox/Linux	HD	545
msbuild /m:4	VBox/Linux	HD	750
msbuild /m:8	VBox/Linux	HD	1944

Using nmake is only about twice slower than under VMware (and 4 times slower than in physical machine) but there is clearly a problem with scheduling if building using 4 concurrent processes takes even longer than this and building using 8 of them is 4 times slower yet (that's half an hour build time instead of half a minute in a physical machine!).

To summarize, there are two conclusions. The most interesting one, if only because it was rather unexpected to me, is that if build times are your primary concern then you should spend your money on an extra Xeon instead of an SSD. I couldn't test it but it seems clear that building using 16 logical CPUs would be much faster than using 8 of them. SSD doesn't provide any advantage at all just because it isn't the bottleneck -- the CPU(s) is/are. Looking at perfmon charts under Windows it is quite clear: the disk utilization hovers around 10% with occasional spikes to 30% but CPU use is pegged at 100% during the entire build (when using msbuild /m:8). Of course, SSD have other advantages. As many people have noticed, booting is much quicker. And so is launching new applications. But personally I just don't care about either: I simply never reboot any of my machines and I mostly work with the same applications which are always running. I do notice that switching between different projects in MSVS IDE is much quicker when using SSD but IMO this doesn't justify the price premium. Undoubtedly I simply don't do enough of disk-intensive work but as much as I try I simply can't muster the same kind of enthusiasm as others have expressed after switching to using an SSD. The main advantage I see is the absolute quiet: although the hard disks are rather quiet as well, they do produce some noise when spinning up after a period of inactivity. But, again, this is hardly a game-changing advantage.

The second conclusion is less unexpected: compilation remains one of the probably worst activities for virtualization from performance point of view. This is somewhat surprising combined with my newly gained knowledge that it is CPU, rather than IO, intensive -- it would seem that it should virtualize very well because of this. But it doesn't, unless you count "twice slower" as being very well. Of course, this is not the end of the world and you could develop for Windows using a VM under Linux. It's certainly very usable and you almost don't notice any difference with the physical machine neither with VMware nor VirtualBox; I seriously considered just putting up with the extra wait (but finally couldn't use Linux on this machine anyhow because of the problems with resuming from suspend and so had no choice but to install Windows anyhow). OTOH you do need to buy VMware Workstation instead of using VirtualBox if you plan to do this (I probably need to add a disclaimer that I'm not affiliated with VMware in any way, I just love using their software even since version 3 and up to version 7 which I bought after doing these benchmarks, it's really invaluable for developing/testing and that you should, of course, compare their performance yourself just in case my case was somehow exceptional).

Autumnal Tidings

2009-11-01T11:48:00.000Z

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

2009-09-12T11:57:00.006Z

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:

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

2009-09-02T16:56:00.001Z

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

2009-08-03T00:00:00.002Z

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:

Vadim Zeitlin (129)
Stefan Csomor (22)
Jaakko Salli (14)
Kevin Ollivier (4)
Mike Wetherell (3)
Vaclav Slavik (3)
Jouk Jansen (2)
Paul Cornett (1)
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

2009-07-25T12:11:00.004Z

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

2009-07-13T06:32:00.000Z

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:

Lack of support for logging from threads other than main.
Impossibility to treat logs from different parts of application differently.
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

2009-07-05T21:44:00.003Z

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

Hints for Editing XRC with Vim

2009-06-17T09:30:00.000Z

If you are one of those strange people who prefer to write XRC files manually instead of using one of the many GUI editors, and also one of the enlightened people using Vim as their text editor you may be interested in this hint: although Vim is smart enough to detect that XRC files are XML without any extra prodding (as the presence of header at start of each XRC file is enough for XML file type detection to work), things can be made more comfortable with a little extra effort.

Before doing anything else you need to modify your .vimrc or _vimrc (under Windows) file to detect XRC files as a separate file type. For this simply add the following line to it:


au BufNewFile,BufReadPost *.xrc set ft=xrc

I also like to start with XML boilerplate already filled in when I create a new file so I additionally have


au BufNewFile *.xrc read ~/vim/template.xrc

where the file template.xrc contains


<?xml version="1.0"?>
<resource>
    <object class="" name="">
    </object>
</resource>

Now, I'd like to do spell checking in the XRC elements which contain user visible text. For this I create the file ~/vim/syntax/xrc.vim (this works under Windows too, just use whatever Vim considers to be your home directory instead of ~) with the following contents:


runtime syntax/xml.vim

syn region xmlString start="\(<title>\)\@<=[A-Z0-9]" end="\(</title>\)\@=" contains=xmlEntity,@Spell
syn region xmlString start="\(<text>\)\@<=[A-Z0-9]" end="\(</text>\)\@=" contains=xmlEntity,@Spell
syn region xmlString start="\(<label>\n\?\)\@<=[A-Z0-9]" end="\(</label>\)\@=" contains=xmlEntity,@Spell

and enjoy Vim help with correcting your mipsellings (how did you notice I wasn't writing this post in Vim?). Notice that the region definition is not very elegant but this was the best way I could find to make it work: using \zs unfortunately didn't work.

Next, I also defined a couple of helpful macros to insert the common constructions into XRC. This is done in ~/vim/ftplugin/xrc.vim (which will be sourced automatically by Vim thanks to our file type autocommand):


runtime! ftplugin/xml.vim

nmap <Leader>o o<object class=""><C-M><Esc>kf"a
nmap <Leader>v o<object class="wxBoxSizer"><C-M><Esc>O<Tab><orient>wxVERTICAL<Esc>o
nmap <Leader>h o<object class="wxBoxSizer"><C-M><Esc>O<Tab><orient>wxHORIZONTAL<Esc>o
nmap <Leader>i o<object class="sizeritem"><C-M><Esc>O<Tab><flag>wxALL<Esc>o<border>5

Notice that this supposes that you have the XML editing plugin installed, notably it relies on it to close all the tags. But surely you don't edit XML in Vim without it anyhow, right?

Much more could probably be done but I find that the above already makes editing XRC much more comfortable. And I definitely can do it much faster in Vim than using any GUI I tried so far.

Spring News

2009-06-04T14:36:00.001Z

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.

Accepted Projects for Google Summer of Code 2009

2009-04-27T15:14:00.003Z

This is a follow up to the previous post about wx acceptance into GSoC 2009. We have had many great proposals this year -- it was the best year for us so far from this point of view IMO -- and the only regret is that only 3 of them could have been accepted, I really feel sorry for some students who have clearly put a good effort in making their application. Nevertheless I can't really be sad about it because the 3 that were accepted look pretty exciting to me. There are:

Bartosz Bekier's project for adding file-system notification events.
Malcolm MacLeod's wxAUI enhancements project.
Peter Cawley's ribbon bar for wxWidgets project.

I'm mentoring the first one of those so I'm naturally quite interested in it but the wxAUI project is clearly very much needed too and in spite of my initial opposition to the idea of including ribbon bar into wx, it turned out to be the most popular proposal among both students and wx users so it definitely will be great to have too.

Finally, just as during the last year GSoC, even if wx itself has only received 3 slots, there is also at least one other wx-related project in a different organization: Perl has one slot for creating Perl bindings for wxWebKit. And Audacity is participating in GSoC again as well and while their projects don't seem to be especially wx-related it is still nice to see wx applications being part of GSoC. OTOH it's a pity that none 30 Python projects seem to be wxPython related, especially as wxPython itself is not part of the GSoC this year but well, like this we have something to hope for the next year :-)

In the meanwhile good luck to Bartosz, Malcolm and Peter and looking forward to their contributions to wx!

Marching Forward

2009-04-04T21:07:00.001Z

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.

Google Summer of Code 2009

2009-03-19T11:28:00.002Z

Excellent news: wxWidgets has been accepted to participate in Google Summer of Code 2009 again! Congratulations to the other 149 accepted organizations but I'm especially glad about this one :-) I admit that I was rather worried about it as we already were lucky enough to be part of GSoC during the last 3 years and it was mentioned that some previously selected organizations couldn't be accepted this year to make place for new ones. But all is well that ends well.

Now we need to attract enough good students applications before the April 3 deadline to be able to choose the best ones of them. And while we also have a list of proposed projects we also are always looking for more so please update the Wiki page or post to our mailing lists if you think you have an interesting idea.

So if you are a wxWidgets user or a user of any wxWidgets application please tell any students around you about the possibility to work on wxWidgets during this summer. And, of course, if you are a student yourself, consider applying!

wx Sightings in the Wild

2009-03-09T22:38:00.004Z

I've just discovered (please don't laugh as apparently everyone else made this discovery a year or at least half a year ago but better late than never) a nice solution for synchronizing files between different machines called Dropbox. For those of you who are as ignorant as me, it's basically a way to transparently rsync files (up to 2GB for free) with Amazon S3 storage. The transparent part is nice as it means that you just run a daemon monitoring the dropbox directory in an efficient way (using inotify under Linux and, my guess would be, using ReadDirectoryChangesW() under Windows) and don't have to manually commit and update your files as I was doing so far, using a central CVS server (from which I'm slowly moving to an hg one). And, unlike CVS, Dropbox also provides a nice way to access your files from any JavaScript-enabled browser (which is more convenient than hg web interface but then it's not at all meant to do the same thing).

The only problem with Dropbox is that the daemon part of their product is not open source. This is really a pity but it also explains why I started looking at its internals at all -- only to discover that it is written using wx, more precisely wxPython. It's not the most demanding GUI application in existence but it's still nice to see that an application used by many (how many? I don't know but judging from amount of stuff written about it on the web this must be one of the most widely used wx applications in existence) people is written in wx and apparently nobody complains about its GUI.

So while I'll probably mostly continue to use hg myself, I'll certainly recommend it to my less DVCS-inclined friends and relatives. And if any of the readers of this blog want to try it out, don't hesitate to use my affiliate link to register and get extra 250MB of space for both you and me.

February 2009 News

2009-02-28T13:00:00.001Z

Maybe it's because February is so short or, more likely, because we started a lot of things in January, but not that many exciting things have happened in wx land during this month. To continue from the last month summary, we did move closer to finalizing the new event handling code, although we had to introduce a new Bind() method (which I'm going to describe in another post soon) as trying to introduce new features while keeping backwards compatibility with the existing code using Connect() proved to be too hard. And the wxYield-related changes were mostly finished too.

Unfortunately not much has been done for the remaining big item for 2.9.0 release: unification of the debug and release builds. This is something which would be really useful for both the library users and developers and actually doing it will probably be not that difficult -- but deciding what exactly should be done proves to be more agonizing than expected. I still hope to do it in March but then I said the same thing about February at the end of January, of course...

There were also some discussions about releases: both 2.8.10 and 2.9.0. Please help us with testing them if you can!

The only new features of note implemented in this month were, AFAICS, the new wxTaskBarIcon implementation for wxGTK by Paul which should look much better in modern desktop environments and support for hints (a.k.a. cue banners or placeholder strings) to wxTextEntry (and hence wxTextCtrl and wxComboBox).

As usual, several bugs were fixed. The most important one was arguably #626 which is a problem with wxTreeCtrl selection events in wxTR_MULTIPLE mode. As can be seen from its number, it was a very long-standing ticket and while the fix hasn't been checked in just yet, it's going to be done very soon -- thanks a lot to Jonathan Liu who spent a lot of time working on this (and several other bugs as well).

Finally, some statistics for February: there were 632 commits in the repository, 67 new tickets were created, 84 were modified and 61 were closed. We'll try to do better in the next month (and preferably not by making Trac crash with internal server error and thus making it impossible for people to enter new tickets... I do love Trac UI and workflow but it's still amazing that it's the only ticketing system which I ever saw crashing -- but then I saw it do this all the time).

That's all for this month folks and have a nice March!

January 2009 Progress Report

2009-01-31T22:04:00.001Z

As the post about wx progress in 2008 seemed to generate quite some interest, here is the promised update for the things we did in the first month of 2009.

The main new addition was probably the long-discussed support for persistent controls. This is not completely done yet but initial implementation of the basic support for persistence was checked in and now persistent adapters for more wxWidgets classes (currently only wxTopLevelWindow and wxBookCtrls are covered) can be added one by one.

Another important change was the integration of the type-safe events patch from Peter Most. Not only it makes the events safer but it also allows connecting anything as an event handler, not necessarily a method of wxEvtHandler-derived class. Unfortunately we hit some problems with building this code with all but the very latest compilers (we didn't even try to use it with VC6, but it was a bad surprise that VC7 template deduction was not smart enough for it neither) so currently it is still disabled but we plan to re-enable it a.s.a.p.

Speaking of the improvements to compile-time safety, Francesco has modified wxWindow::ProcessEvent to be protected at wxWindow level as it should never be called directly but only as win->GetEventHandler()->ProcessEvent() or, with the latest trunk, as win->ProcessWindowEvent() which does the same thing, to avoid skipping any event handlers pushed onto the window. Doing this allowed to find several places in wxWidgets itself where GetEventHandler() call was forgotten and there are certainly a lot of similar omissions in code outside of wx itself which this change will now allow to find during compile-time.

There was also more work done on the native headers (with nice support of sorting and column reordering) in wxDataViewCtrl and wxGrid (special thanks to Zen Fire for sponsoring this work!) and on wxDataViewCtrl in general. In particular the simple wxDataViewListCtrl wrapper was added and event-based API for drag-and-drop was implemented.

The last problems with support for custom controls in native file dialogs under Windows were solved thanks to Marcin so now only Mac support for this feature is missing. Speaking of Mac, the new OS X port kept progressing in leaps and bounds and I'm especially glad that several people have contributed to it recently -- thanks!

Then there were some improvements to MDI stuff. This code was not updated for a long time so I started reviewing and correcting it in last November and continued to do so, while adding some new features, now.

And finally some useless statistics: so far (the month is not quite over yet...) there were 850 check ins in January. 138 new tickets were created, 211 ones were closed (at least we're moving in the right direction!) and Trac records 365 ticket modifications in total from 93 different people (with Robin and me doing most of the damage with about 70 changes each).

On a completely unrelated note, I've installed, out of curiosity, beta of Windows 7 and tested some wx samples under it. They have no special support of Windows 7 (nor even Vista yet) but they still appear to be quite fine, only small details (e.g. owner drawn menu items) look out of place. I'm not sure if this can really be seen as our merit though, it's probably more a compliment to Microsoft for maintaining backwards compatibility. Although it also clearly shows the advantage of using native controls -- I doubt that the programs written using Qt, especially using its version from a few years ago, look as good as the ones written even very old wx versions under the new system. Other than that, my main impression of Windows 7 is that it's amazing that it still needs to restart when changing the workgroup name. I guess they didn't want to remove all old and familiar features at once...

And to end this post, some less technical news: we made a brief roadmap for 3.0 release. This is not much in itself but it does help to concentrate thoughts on it and hopefully gives a bit more visibility into the project future for people not reading this blog.

And I was extremely glad to learn that wxWidgets now has a new maintainer in Debian as I almost lost hope to ever see them there as the old maintainer spent his time only sabotaging the efforts by others to bring wx to Debian and spreading FUD about it in his spare time whereas the new maintainer has already released the updated packages which is great news for me both from a wx developer and a Debian user viewpoint. We also had a discussion with Dan Horák, Fedora packager of wxGTK, about supporting multiarch (mostly x86/amd64) packages and making RPMs for wxWidgets 3.0 (interested people can already try these experimental pre-2.9 versions).

Qt switch to LGPL

2009-01-14T22:07:00.002Z

Qt switch to LGPL has triggered a thread with subject "Bad thing for wxWidgets Qt will be in LGPL" on wx-users mailing list which clearly implies that this is indeed a bad thing. But is it one really?

First, let's not be egoistic: even if this were bad for wx, it's surely excellent news for just about everybody [else]. I do applaud Nokia for doing the right thing and I'm personally very glad that even people in big multinational companies such as Nokia understand the benefits of open source.

Second, this certainly will bring more users to Qt. But I'm not sure it's going to happen at the expense of wxWidgets users. I rather think more people thinking to use Java or C# or C (with GTK) could reconsider their choice and use C++ with Qt. The reason for this cautious optimism is that the cost of Qt has never been the only reason for choosing wxWidgets over it. Of course, this hasn't ever been important for GPL applications anyhow. And, surprisingly, it often wasn't very important for commercial applications neither as companies often choose to pay for wxWidgets support anyhow even if the library itself is free. So I think that relatively few of people who had chosen wxWidgets in the past would change their mind now, as the other two main reasons for this choice -- the use of native widgets by wxWidgets and the absence of any preprocessor -- remain as valid as ever.

Finally, if more people use C++ for developing cross-platform applications this is good for wxWidgets even if they use Qt because the whole idea of writing portable programs is unfortunately still not as entrenched in mass conscience as it should be in our opinion. So this could yet turn out to be positive for wxWidgets, although more likely it's not going to change much for us one way or the other.

But this remains great news for the open source community (of which we are part) so I just can't bring myself to regret it. I can dream about wxTNG which would combine the best features of wx and Qt but this still remains a dream for now...

Another Year of WX

2009-01-06T00:49:00.000Z

I wanted to write this summary of the work done on wx in 2008 before the end of the year but, as it unfortunately often happens, ran out of time and couldn't do it. Still, better late than never -- again this is a very familiar principle -- and so here is a brief summary of important things which happened to wx in 2008. It liberally reuses the material from Robert's Wonderful World of WX write up, read it for more details.

So, what have we done in the almost 7000 revisions checked in during 2008? Maybe surprisingly, the most important changes haven't been about writing code at all but rather about improving the project infrastructure. This may not seem like a big deal but the old SourceForge-based bug tracker was completely unusable and basically was unused because of this and literally hundreds of bugs could have been triaged and closed since the switch to using Trac. We also finally have a working BuildBot which allows to detect breaking the build (and assigning the blame) quickly and automatically and this is very useful for a project such as wx where it's not always possible to test the compilation of the new code in all configurations under all platforms. Finally, the documentation now is in a new Doxygen-based format which makes it easier to maintain and contribute to it, as well as producing nicer results.

By the way, you might have noticed that one of the goals of these changes was to make it easier to contribute to wxWidgets:

Trac not only allows us to process bugs more efficiently but will hopefully also encourage others to to help with weeding out the duplicates (something we really couldn't expect the others to do with the SourceForge tracker as we couldn't even do it ourselves). And it allows for better bug categorizations, for instance you can see all easy to fix bugs at a glance and hopefully this can encourage more people to try fixing them (the list is short right now but will probably become longer with time).

The BuildBot allows to verify that the svn trunk version at least builds which is supposed to encourage people trying it out. We also hope to get more volunteers setting up their own build slaves to help us test even more configurations.

And the new documentation format has already allowed many more people to submit contributions to the manual than before and we hope that this trend is going to continue. And using Doxygen further lowers the barrier to entry to wxWidgets development as no LaTeX knowledge is needed any more.

But while waiting for the success of our diabolic plans to make wxWidgets users work on improving the library themselves we still found time to do quite a few things ourselves. From the strategical perspective the most important change of 2008 was certainly the decision to start merging the old Carbon-based wxMac port and the alpha-quality wxCocoa into the new, one and only, wxOSX port which will run on both 32 and 64 bit platforms and also iPods and iPhones and not just the boring desktops. And as a side note, wxOSX can now also be built as a framework and not just as plain old Unix-style dynamic library.

Another strategic decision was to concentrate more on the quality of the library than on the quantity of the things it may do. This has led to dropping of ODBC library which was embarrassingly buggy and unmaintained since a very long time and spending a lot of effort on bug fixing, including the inconsistencies in behaviour between different ports (and while this post intentionally doesn't cite any names to avoid accidentally omitting somebody, I do have to thank once again Google for organizing, once again, the Summer of Code which allowed us to spend more resources than would have otherwise been possible on this task -- let's give credit where it is due). In the same category, we have finally cleaned up wxSocket and wxURL code which became an acute embarrassment to all of us after a decade of bit-rotting and also fixed some, although by far not all, problems with wxGrid which also suffered from chronic lack of attention.

Of course, all this doesn't mean that there were no new features added so let me list the most important ones:

The first among them was the long-awaited inclusion of wxPropertyGrid in wxWidgets itself.

wxDataViewCtrl and related classes continued to be significantly enhanced.

wxRichTextCtrl has benefited from many small but cumulatively important improvements as well.

As part of improving wxGrid/wxListCtrl columns display support, a new wxHeaderCtrl class was added and a handy wxRearrangeList and related classes were added and column reordering was implemented.

A convenient new sizer class, wxWrapSizer, was added.

wxCalendarCtrl now has a native implementation.

The humble wxMessageDialog got a much needed face lift as well, in particular you can finally use custom labels for its buttons

We even found something to improve in wxStaticText which now supports "ellipsization" of its contents.

wxGLCanvas gained anti-aliasing (multi-sampling) support.

The main -- but far from only -- change to AUI library was the addition of wxAuiToolBar.

Events (and hence timers and asynchronous sockets) support was finally added to wxBase, after years of planning to do it.

And I probably forget quite a few more.

But while things have progressed quite a lot, we didn't manage to do everything we'd have liked to, of course (otherwise what would be doing this year?). My main regret is that we didn't manage to release 2.9.0 development branch preview release as I'd really like to do this a.s.a.p. to get more feedback about the Unicode-related changes. Among the features we hoped to add this year but didn't one really stands out: a lot of people are asking for images support in wxButton and we really should support this as it's not even difficult to do so this will definitely be something to do in 2009.

The two other small things we hope to see in this new year are the wxOSX completion and hopefully the 3.0 release. Let's see if this happens...

That's all for 2008 and see you in a year time (unless people find this post really interesting, in which case I might try to write monthly summaries of wx development)!

P.S. Edited to correct the date on 2009-01-09.

Pretty printing wxStuff in gdb

2009-01-04T21:05:00.004Z

I've recently stumbled upon a highly informative series of articles by Tom Tromey, one of gdb developers (among other things), about embedded Python in new gdb. The one immediately useful consequence of this is that you can now write pretty printers for custom data structures as explained here. Unlike the custom gdb commands, the custom pretty-printers apply to all occurrences of the objects, including as fields in the other data structures and even in the backtraces printed by gdb itself so they are much more useful.

So without further ado here is a pretty printer for wxString from svn trunk (it can also be trivially adapted for 2.8 version by using m_impl.m_pchData) shamelessly stolen from the examples above:


class wxStringPrinter:
 def __init__(self, val):
     self.val = val

 def to_string(self):
     return '"' + self.val['m_impl']['_M_dataplus']['_M_p'].string() + '"'

gdb.pretty_printers['^wxString$'] = wxStringPrinter

This is supposed to be put into a file sourced with source -p gdb command (there is apparently a better way to load this than simply inserting the command in .gdbinit but for now this is good enough for me).

And then:


[sunset:../src/build/wx-gtkud/samples/minimal]% gdb minimal
(gdb) b 149
Breakpoint 1 at 0x40cc65: file /usr/local/src/wx/HEAD/samples/minimal/minimal.cpp, line 149. (2 locations)
(gdb) r
Starting program: /usr/local/src/build/wx-gtkud/samples/minimal/minimal
[Thread debugging using libthread_db enabled]

Breakpoint 1, MyFrame (this=0x5751a0,title="Minimal wxWidgets App") at /usr/local/src/wx/HEAD/samples/minimal/minimal.cpp:149
149         SetIcon(wxICON(sample));
(gdb) bt 1
#0  MyFrame (this=0x5751a0, title="Minimal wxWidgets App") at /usr/local/src/wx/HEAD/samples/minimal/minimal.cpp:149
(gdb) p title
$1 = "Minimal wxWidgets App"

Of course, you do need a Python-enabled gdb for this to work. The easiest way is probably to get the package from Debian Experimental as I did. Otherwise you can always follow the instructions on Tom's blog and get gdb sources from git and built them yourself.

But this is really incredibly useful and will be even more so when we add pretty-printers for the other wxWidgets types (e.g. wxDateTime could definitely benefit). Any contributions to our custom pretty-printers would be welcome!

Fun with benchmarks

2008-08-08T00:56:00.002Z

I was looking into optimizing the new UTF-8 string class in wxWidgets 3 and I had to decide about the most efficient way to cache information about mapping UTF-8 positions into byte offsets. So I wrote a simple benchmark to measure the overhead of using the thread-specific variables compared to using normal globals.

To be precise I wrote a simple loop updating the variable (which is, of course, not at all realistic but that's micro benchmarks for you) using the following methods:

Direct global variable access

Using compiler thread-specific variables support (__thread for g++ and __declspec(thread) for MSVC)

Using OS-specific TLS support (Win32 TLS or POSIX threads TSD)

Using boost::thread_specific_ptr

The results were somewhat surprising, although also encouraging: under both Win32 (x86) and Linux (amd64) platforms the first two ways were the fastest. The OS functions were 3 times slower under Windows and 5 times slower under Linux. Boost implementation was disappointing, at least from performance point of view as it was 2 times slower than OS functions, making it 6 or 10 slower than the fastest version. This is bad news as I hoped to avoid writing a wxWidgets-specific TLS class and just use Boost version but this doesn't seem a good idea for performance-sensitive code.

But the biggest surprise, at least for me, came from the comparison of the first two approaches: using compiler support for thread-specific variables turns out to be faster than using plain old globals. This was so unexpected that I even checked the disassembly to see if I wasn't missing anything and it turns out that gcc generated exactly the same code for both versions except that in the thread-specific version it used FS-relative addressing to access the value. For MSVC the code wasn't quite the same but it also used FS for thread-specific variable. So it looks that under both x86 and amd64 using FS register is actually faster than using normal absolute addressing.

In any case, it's good to know that having thread-specific variables brings no performance loss when they are supported by the compiler. Of course, my benchmarks are very specific and, last but not least, they don't have any thread running. However I think the results should be broadly true for more realistic code which I'm going to benchmark once the real caching implementation is written.

What you can learn by reading Slashdot

2008-05-27T22:04:00.002Z

Slashdot had an interesting post today linking to a project which studied the degree of separation between different Wikipedia articles. Possibly moved by the subconscious feeling of shame due to the fact I was reading Slashdot instead of working on wx I decided to check what does it have to say about the closeness of wxWidgets to paradise. And the result was:

Shortest path from wxwidgets to paradise
WxWidgets
November 27
Eastern Orthodox Church
Paradise
3 clicks needed

I say we're pretty close to the goal! Even better, while we're only 3 clicks removed from Qt too, Qt itself is 1 click further from paradise than wx is. They have some work to do (but then maybe this is what they're doing, instead of reading Slashdot...)

Google Summer of Code 2008 and wx

2008-04-29T12:00:00.002Z

Since a couple of years, there is something we really look forward to each spring. I'm not speaking about blossoming flowers and all this nonsense, of course, but about the Google summer of code. This is a wonderful program which gives many open source projects, including wx, an opportunity to work on some projects which wouldn't be started otherwise because they require initial investment beyond what we can normally afford and attract new contributors to the project.

So it's great to be part of GSoC again, even though -- let me perform some ritualistic whining -- we got only 2 slots this year while we had 3 of them during the previous ones. I'm not sure why did this happen (probably because ever more projects take part in the program and even Google's budget is not unlimited) but it might be related to the relatively few students proposals we received this year (about a dozen and 5 of them about the same project). Of course, there were still some worthy proposals which got cut (at least the third and the fourth one) but I still think that one of the goals for the next year should be to prepare more interesting projects and try to attract more interest -- and if you have any great ideas, please let us know or just add them to this wiki page.

Of course, while wxWidgets itself has 2 slots, there are other wx-related projects undertaken by the other organizations. wxPython has 3 more slots, Audacity uses one of its 5 for writing new draggable sizer classes which could hopefully be reused by other projects and even Perl has wxCPANPLUS project using wx. So the life is still good.

But it will be even better once our 2 projects are completed. Personally I'm mostly excited about the "duller" one of them -- the bug fixing one by Marcin Wojdyr. We currently have an indecent number of open bugs (~1600 at the last count) in our bug tracker and this is way too much, in fact there are so many of them that even finding an existing bug is difficult. This is partly due to the extremely poor SourceForge bug tracker UI so one of the first steps in this project will be migrating all our bugs and patches to Trac. And then, of course, fixing some of them. This is probably not as exciting as writing some great new control but almost certainly is more useful to wxWidgets and will do more for our users so, once again, we're really glad to have the opportunity to do it during this GSoC!

Programming for the Eee PC with wxWidgets

2007-12-10T12:55:00.000Z

There has been a lot of fuss about the Asus Eee PC in the last few months and Asus have clearly pressed the right consumer buttons with their cheap Linux subnotebook. No doubt there will be many more machines in this format in the future, representing a market of many millions, so it’s an attractive target for developers. Fortunately for wxWidgets programmers, it’s pretty straightforward to adapt wxGTK applications to the requirements of the Eee PC. This consists mainly of two tasks: fitting windows and dialogs onto the 800x480 screen, and distributing the application in a Xandros-friendly package (a .deb).

Here’s an example of one of my wxWidgets applications (Writer's Café) running on the Eee PC:

Should I port my application?

First, a few observations about the Eee PC from the perspective of a developer wondering whether his or her application would be a good match for it. What kind of users are we talking about? Well, it’s such a general-purpose machine it’s hard to narrow it down, but it obviously has appeal to children and women who generally have smallish hands and could more easily adapt to the diminutive keyboard. But at least for casual use, most people could get used to the form factor, and some tasks don’t need much keyboard use, such as browsing, listening to music or reading e-books.

There are plenty of reports of people using the Eee PC for substantial work – it’s good for journalists, photographers, students, and business travellers (although the limited battery life could be a problem on long trips). It could be useful for accountants visiting client premises, for example, or engineers often on the road. The Eee PC enthusiasts’ forums are full of examples of both business and home use. Unlike smaller devices such as the Nokia N series of internet tablets, or Windows Mobile devices, the usable keyboard means that this machine has the potential for running a fuller range of applications, albeit for shorter periods of time than on a larger computer (due to comfort and battery limitations). The high level of compatibility of files and applications between conventional PCs and the Eee PC increases the appeal of performing regular PC work on a highly mobile machine.

Apart from the small keyboard, the main limiting factor is probably not so much the slower processor as the low-resolution screen. However, people are getting used to it and one user has reported that they find a regular screen too big now, and they have to emulate the Eee PC resolution on their desktop!

So, the answer to the question, “Is it worth porting my app to the Eee PC?” is probably going to be “Yes” in most cases. If you’re already writing wxGTK applications, it’s almost a no-brainer. Apart from anything else, there’s a “cool factor” in showing your applications running on the gadget.

Starting wxGTK development

If you are targetting the Eee PC running Linux, then you will use the wxGTK port (wxWidgets on top of GTK+ 2). As a bonus, your work in tailoring applications to the Eee PC display size will also pay off when recompiling your applications for Windows, to target Eee PC running the Microsoft operating system.

There are many combinations of working methods and tools for writing wxGTK applications. I do most of my development on a Windows PC, and compile the apps on Debian Edge running on the same machine (using VMware) for deployment on Linux. The resulting wxGTK application runs on most modern Linux distributions, which all tend to come with the necessary GTK+ 2 libraries regardless of desktop environment in use. The Eee PC’s Xandros is no exception. The .deb archive I distribute for use on standard GNOME and KDE Linux desktops is the same used for the Eee PC, and the applications dynamically adapt to the display in use. Obviously if you’re going to deliver on an Eee PC it helps to have one for testing purposes – although you can do a certain amount of testing by reducing the resolution, you still need to check the installation and performance on real hardware. Having said that, debugging wxGTK-specific issues can mostly be done within the comfort of a spacious Linux desktop using a distro such as Debian, Ubuntu or Xandros.

As for all wxGTK development, you need the GCC compiler (available preinstalled on most Linux distributions), and the GTK+ 2 development libraries (search for the gtk2.0-dev package). For decent printing support, don't forget to install the libgnomeprintui2.2-dev package also before configuring and compiling wxWidgets. Get the latest version of wxWidgets in the 2.8 series, for example wxGTK-2.8.7.tar.gz at the time of writing. You can use plain old Emacs and gdb to write and debug apps, but you may wish to consider IDEs such as Anjuta and Code::Blocks, and for generating code, dialog editors/RAD tools such as DialogBlocks and wxDesigner. Basically, anything that applies to wxGTK development also applies to Eee PC/Xandros development.

If you decide to use DialogBlocks, both to generate first-cut application skeletons and to help generate detailed dialogs, DialogBlocks will help you compile wxWidgets as well as your own app. Create a project (or try one of the samples), select the configuration you want to use, set the wxWidgets path, and DialogBlocks will first compile wxWidgets before compiling the project.

Adapting to the low resolution screen

The following is applicable to any device with a low resolution, so it’ll help you prepare for future Linux-based mobile devices too. It’s also applicable to other operating systems that wxWidgets supports, such as Windows and Mac OS X.

Your first step might be to add a full-screen mode. This is straightforward in wxWidgets, using the wxTopLevelWindow::ShowFullScreen function. The usual shortcut key for this is F11. From wxWidgets 2.8.7, menu accelerators on wxGTK are still active even if the menubar has been removed, so the user can press F11 to restore the window to normal viewing. ShowFullScreen can retain your toolbar, or hide it, depending on your application’s requiremements. If your main window still uses a lot of space for non-essential control windows (for example tabs and extra toolbars), then you might consider reparenting the editing window to a new frame and showing that full-screen, subsequently reparenting the window back when the user returns the window to normal.

Note that currently on wxGTK, the toolbar is restored when returning to normal view, even if the toolbar was previously hidden. You may need to add some extra logic to hide the toolbar explicitly.

Also note another quirk if you’re planning to show a frame full-screen when the program starts – the window may show in its initial size momentarily, then resize to fit the screen. You can mitigate this effect by making the initial window size very small, say wxSize(1, 1).

You may find you made assumptions about screen size when designing elements of your main screen. Palettes, tabs and toolbars can look rather huge and leave little space for editing, especially when even a maximised main window has to compete with a largish title bar at its top, and a taskbar at the bottom of the Eee PC desktop. Here are some ideas for further adaptations:

Add an option for small toolbar icons if your toolbar currently has large ones. Also make it possible to switch toolbar labels off, and remove inessential tools for low-resolution displays.
Add an option to hide the toolbar and status bar.
Use wxAuiNotebook for a tabbed interface, and set the notebook font to a couple of sizes smaller than normal. Native GTK+ tabs can be rather large.
Use wxWindow::SetWindowVariant to set a smaller font size for panels.
Use a wxChoicebook instead of wxNotebook for a tabbed palette, to reduce the vertical size requirement.
Maximise the main window by default on a small screen.
Make sure there are accelerators for important operations, so that the program is still usable when full-screen and without a toolbar or menubar.
Consider a vertical toolbar or other control window to the left or right of your main editing area, since vertical space is in shortest supply.
Use a wxScrolledWindow for larger panels containing controls. You can just replace the wxPanel base class with wxScrolledWindow, and call SetScrollRate to enable the scrollbars.

I have a function I use to test for a small screen – HasSmallScreen – which I use to make UI choices as the windows are created. You can have a balance of customisable and non-customisable choices: you might want everything to be under user control, or you might not want to burden the user with so many choices. But the defaults should reflect the best choices for the display resolution.

Making your dialogs fit

Probably the area you’ll find in need of most work is your application’s dialogs. You may find that some or all of them they disappear off the edge of the screen, especially vertically. There are several techniques you can apply here. Firstly, you can set the initial size of individual controls (such as listboxes) to be smaller when a small display is detected. You can also use wxWindow::SetWindowVariant, and simply omit certain controls and explanations from the dialog. You can do this by creating all elements as usual, but hiding some of them before showing the dialog, for example:

GetSizer()->Show(m_description, false);

In DialogBlocks, you can make sure the control and its sizer parent both have member names, and then before the end of CreateControls() write something like:

m_innerSizer->Show(m_furtherInfo, false);

You may find that after these adjustments, and others including dividing up the dialog into pages, your dialogs will fit. If not, you can take more drastic action using scrolled windows.

To make an ordinary custom dialog scrollable, add a wxScrolledWindow under the top sizer, add a sizer to the scrolled window, and place the main controls under that sizer. Keep the OK and Cancel button row under the dialog’s main sizer so only the main content of the dialog scrolls, leaving the OK and Cancel buttons accessible at all times. Initially, don’t make the scrolled window scrollable. If you are using DialogBlocks, set PPU X and PPU Y to zero and ensure “Fit to content” is checked and also that the wxNO_BORDER and wxTAB_TRAVERSAL styles are checked. When you have done this, the dialog should behave exactly as before, when wxSizer::SetSizeHints is called and the dialog shown.

Now you need to check whether the dialog size is the same or more than the available desktop client size. wxSizer::Fit (called by wxSizer::SetSizeHints) attempts to restrict the dialog to the available space, so you need to assume that if one or both dimensions are the same as the desktop dimensions, the dialog was too big and has been resized. If the whole dialog couldn’t fit, you need to enable the scrolled window’s scrollbars and resize the dialog, taking into account the dialog titlebar which wxWidgets 2.8 doesn’t currently do itself.

A simple example built with DialogBlocks is available as a zip file and as a tar.gz file from http://www.anthemion.co.uk/wx/largedialog.tar.gz or http://www.anthemion.co.uk/wx/largedialog.zip. You can use the demo version of DialogBlocks to build and run the sample, or you can adapt the makefile as you see fit, or you can simply copy and paste the relevant code for your own applications. The images below show the dialog first on a regular-sized Debian desktop (no scrollbar), and secondly on a 640x480 display (a vertical scrollbar appears).

The function that does the work is wxFitWithScrolling, in mydialog.cpp, which you can use with any dialog that has a scrolling part. Use it instead of wxSizer::Fit or wxSizer::SetSizeHints.

What if you have a lot of dialogs, and don't want to spend time customizing them? No problem - just replace wxDialog with wxScrollingDialog, a class that rejigs an existing hierarchy to keep the standard buttons shown. You can download the class here.

Distributing your application

While it’s best to create a .deb archive, you could also distribute a tarball. For a shortcut to making Debian archives, see checkinstall. For creating a .deb from scratch, see for example here and here.

The .deb or your installation script should also install desktop files and MIME type files. These are standards documented by Freedesktop.org in particular the .desktop file standard. When you install your .desktop files and icons into the appropriate place, and specify the application category, the KDE or GNOME desktop environment will know where to put your application’s shortcut(s) on its menus. However, most people may be using the standard IceWM window manager – the old version in use on Xandros doesn’t follow Freedesktop.org standards and you will need to add the ability to enable the Start menu and add your application’s menu items. I do this with a script that’s included in my application files, so the user can run the script to complete the installation. It’s separate, in case the user isn’t running IceWM. The script creates local IceWM preferences and enables the Start menu; then it appends an entry to the menu file if it’s not already there. The user should reboot X with Ctrl+Alt+Backspace for the changes to take effect.

An example script is available here.

That’s all for now. Good luck with your Eee PC projects! I think the Eee PC and wxWidgets make a great combination, and it will be interesting to see how the market for desktop Linux will develop over the coming months.

Hildonizing wxGTK

2007-11-25T23:19:00.000Z

Last week-end I have somehow managed to find myself with a couple of hours of free time and, instead of spending them on fixing random wxWidgets bugs as usual, I wanted to actually do something new and different for once and so chose to check how wx applications look on a Nokia 770 tablet. Several people have talked about porting wxWidgets to this device in the past and at least one has apparently done some work but it was almost two years ago and nothing has happened since, so I felt it was time to do something about it myself; especially as I own a N770 tablet since quite some time but, instead of writing programs for it as originally planned, I've so far spent time just using it (I do feel ashamed).

For those who don't know about Nokia internet tablets line, which started with N770 but has been extended with N800 and N810 since then, they're small handheld non phone devices which run Linux and use a modified Gnome desktop version called Maemo. Maemo basically just adds another level of libraries, called Hildon on top of GTK+ itself. So, while GTK+ applications can mostly run on N770 without changing, they don't have the correct look and feel before they are hildonized, that is modified to use Hildon-specific functions instead of the generic GTK+ ones -- hence the somewhat barbaric adjective used in the title of this article.

This is the theory, anyhow. And I've decided to check how it was in practice. The first results were encouraging: after a few simple fixes, wxGTK did build for Maemo and I could run applications on my device. However they really didn't look like they belonged here as can be seen by comparing the dialogs sample:

with a native application, such as this one:

You can immediately see several differences:

The border of the window are not the same, the wx example doesn't fit into the desktop
The menus are completely different: the native applications don't show a menu bar but use the drop down menus attached to the window itself
The wx example shows a useless status bar with an even more useless resize grip (the window can't be resized anyhow)

So I set about fixing this and after a couple of hours of hacking here is what I got:

This is already much better: the points mentioned above were corrected and I also added a new class (which is available, and hopefully will be useful, under the other platforms too) called wxNotificationMessage and which is used by the small message in the upper right part of the window (such messages are often used in Maemo UI as notifications and also message box replacements)

Of course, there are a lot of other things to do. For one, wxToolBar needs to be changed in the same way wxMenuBar was. Next, as Maemo replaces almost all of the standard GTK+ dialogs with its own ones, we need to do it too. I did it for the colour selection dialog which looks like this now if wxWidgets was built with --with-hildon option:

And the same should be done for the file selection dialogs and several other ones.

There are also less trivial things to do, like to understand how can the size of the library (and of the applications using it) be reduced to be more in line with the embedded systems capabilities. But globally I think wxWidgets is perfectly viable for developing Maemo applications and is even more convenient for doing this than raw GTK+ (which is the native toolkit of the platform) because it transparently abstracts the differences between the desktop GTK+ and Maemo systems: the dialogs sample itself hasn't been modified at all (just extended to show the notification message) to use the correct menus and so on, everything is done inside the library so exactly the same code can be used for the desktop application without any loss in functionality. Of course, in practice you will need to adapt applications to the mobile devices by probably removing some functionality which doesn't make sense there and simplifying the user interface. But wxWidgets already does some of this for you and hopefully will do even more in the future.

Of course, I don't actually expect to have that much free time every week-end so the progress of wxMaemo depends on the help from others. So if you're interested in checking out wxMaemo for yourself, don't hesitate to grab the latest wx code from our svn and build it with the above-mentioned --with-hildon option under Scratchbox. If you are new to Maemo, notice that its web site has nice tutorial about setting up the development environment for this platform. And, of course, if you can contribute to this effort, don't hesitate to send us patches and join us in discussions on wx-dev.

Have fun!

Looking forward to wxWidgets 3

2007-11-04T14:53:00.000Z

The first alpha version of wxWidgets 2.0 was released 10 and a half years ago and we are still (only) at version 2.8.6 right now so the wxWidgets version numbers don't change very quickly as we, with the disdain proper to free software developers, don't really like inflating them for marketing purposes. However soon -- hopefully in the beginning of the next year -- we will release wxWidgets 3.0 which will be the first change of major version since a long time and only the second time it happens in wxWidgets history. So it may be interesting to look at what exactly has changed to warrant this and I'll try to briefly describe it in this post.

First, a word of reassurance: there are no sweeping backwards-incompatible changes in wxWidgets 3.0 compared to 2.8. We did have to break compatibility in a few places but fixing the existing code to compile with 3.0 will be trivial, if needed at all, unlike 1.0 -> 2.0 transition which required rewriting it.

Second, the main change in 3.0 is the rethought support of Unicode. While wxWidgets supports Unicode since quite a long time, so far it did according to Win32 model: there were two different builds of the library, one ANSI and the other Unicode and you could either use the former to use the familiar char * strings but stay limited to a single encoding or choose the latter one and be able to use Unicode in the GUI but at the price of working with wchar_t * string only which implied using ugly-looking wxT() macro in a lot of places for example. wxWidgets 3.0 will have only one build (which on its own is a great simplification for developers, packagers and even users who won't hesitate between which one to choose) combining the best features of the two: it will always use Unicode internally but support char * string and simply convert them using the current encoding transparently. In other words, you will be able to write code in exactly the same way as with the old ANSI build if this is all you need but profit from the full Unicode support at the same time. This is especially nice for the existing wxWidgets applications which weren't always written with Unicode in mind and so often didn't even compile with the Unicode build of wx -- now they will and it will be possible to extend them to deal with Unicode at leisure instead of spending a big initial effort on wxT()-izing them first.

wxWidgets 3.0 is still work in progress, in particular documentation hasn't been updated to reflect the changes yet. However the API and the code are believed to be stable enough to be used and we'd welcome any feedback on the new API. In particular, please try recompiling the existing code with the version currently in the svn trunk and let us know about any problems you may encounter (other than those which are mentioned in docs/changes.txt: please read it first!).

There are, of course, many other new features in wxWidgets 3.0 (without speaking about the bug fixes...):

The new wxDataViewCtrl class provides all the features lacking in wxListCtrl and a much better and simpler API to use them.
There is a new wxDFB (DirectFB-based) port especially suitable for the embedded devices.
wxGTK (and wxDFB) are also more efficient internally because they use UTF-8 for the string representation, instead of wchar_t and so avoid the conversions between the underlying toolkit strings and wxString.
New and improved wxFileCtrl (thanks to Google summer of code).
Many enhancements to wxRichTextCtrl.
Important improvements to several controls under wxGTK, including wxToolBar, wxStaticText, wxHyperlinkCtrl and others.
Support for auto-completion in wxTextCtrl and wxComboBox.

But, again, the most important change by far is the merge of ANSI and Unicode builds and the resulting changes to wxString. As this is the biggest change to wxWidgets API since several years we'd really welcome your comments on it, this will help us release 3.0 sooner and better!

wxWidgets in Leopard

2007-04-15T06:04:00.000Z

The new schedule of Apple's OS X 10.5 a.k.a. Leopard (to ship in October) allows us to get a newer version of 2.8 into the builds. So we aim for a 2.8.4 Release Candidate around the end of April, synching wxPython and wxPerl with it.

wxWidgets under Vista

2007-02-05T19:16:00.000Z

I've decided to (finally) test how do wxWidgets applications fare under Windows Vista. Installing Vista (in a VMware Workstation 6 Beta virtual machine under a Debian amd64 host) turned out to be more problematic than I thought as the MSDN disk 2429.5 contains exactly 4 ISO images of Vista CDs while the installer asked me to insert disk 5 and as I didn't have I couldn't continue with the installation. So I had to install the Enterprise Edition from the disk 2430.2 which not only comes with 4 CD images on the DVD but also actually installs from them.

Other than that, installation was pretty uneventful and un-wow: the installer warns that the computer must reboot several times during the installation -- and so it does. Why no other system among those I installed (various Linux distributions, FreeBSD, Mac OS X, ...) needs to reboot even once? Anyhow, UI-wise the only useful information from the installer is that Vista seems to use ./../... animation as an indeterminate progress control (OS X, or Firefox which probably copied it from it, use a small spinning wheel for the same thing) so if we ever implement a separate control for this, we know how it should look under Windows now.

After finishing the installation and getting rid of half a dozen of the icons in the taskbar notification area (this is progress, I think XP had only a couple of them) I could finally run the widgets sample. The only problem I could see with it was with wxNotebook tabs on the left or right: this doesn't work at all under Vista and I think we should just abandon trying to make it work as it already was pretty buggy under XP.

But there are a few enhancements we could implement, of course:

wxSearchCtrl doesn't look native but Vista does has a native version (just as OS X) and uses it everywhere so it's really jarring to have a different one in wx programs. Apparently the standard "Search Control" class is just a combination of "Edit" and "ToolbarWindow32" (with "Static" thrown in to show the inactive control contents) so we could emulate it easily even on pre-Vista systems. Or we could just use the native control, of course.

Buttons with images seem finally to be supported (they can be seen in e.g. "Tools" page of a disk properties dialog), so we should update wxButton to support this too.

As mentioned before, some file dialogs (e.g. Ctrl-O one in the dialogs sample) use old style while other ones (Ctrl-Q one) use a new style one which is inconsistent at best. Other dialogs seem to be just fine though, and the new Vista-style icons are used everywhere as expected, e.g. in the log dialog. Funny enough, the standard Vista error message dialog now looks a lot like wxWidgets standard log dialog with its "Details >>" button.

All in all I think wxWidgets applications look pretty decently under Vista, especially considering that we didn't spend any effort at all so far on porting the code to Vista. Of course, it's a tribute to Microsoft engineers backwards compatibility maintaining skills more than anything we did but it's still nice, especially compared with the transition to XP when previously working code started to crash and a lot of things didn't look right at all.

In Praise of Connect()

2007-01-26T00:39:00.000Z

In this post I'd like to address a common misconception about wxWidgets which is that it is somehow dirty and beneath consideration of "real" C++ programmers because it relies too much on preprocessor macros. While it is true that the traditional way to handle events in wxWidgets is using the macro-based event tables, there is nothing really dirty nor evil about these macros: they are there simply to save typing. In particular, they don't suffer from the usual macro pitfalls as they don't have any side effects and are type-safe (static_cast is used internally to ensure this).

However the main point is that the event tables macros are just one of two ways of connecting the event handlers to events in wxWidgets and it's perfectly possible to not use them at all. Moreover, there are good reasons to use the alternative way beyond the subjective dislike of macros. This other way is the Connect() method which, unsurprisingly, allows to connect a method of a class derived from wxEvtHandler (which includes, but is not limited to, any wxWindow-derived class) to an event.

The syntax is slightly more verbose which is, of course, one of the reasons for using the event table macros in the first place, they simply save some typing. So instead of

BEGIN_EVENT_TABLE(MyFrame, wxFrame) EVT_MENU(wxID_EXIT, MyFrame::OnQuit) END_EVENT_TABLE()

you need to write (in the body of some method of MyFrame and not at global scope as with the event tables)

MyFrame::MyFrame(...) { Connect(wxID_EXIT, wxEVT_COMMAND_MENU_SELECTED, wxCommandEventHandler(MyFrame::OnQuit)); }

Notice the use of wxCommandEventHandler which ensures that the method is of correct type by using static_cast in the same way as event table macros do it.

So we see that all uses of event table macros can be trivially replaced with Connect() calls. However Connect() is more powerful than macros and can do a few things that macros are incapable of:

Event handlers can be connected at any moment, e.g. it's possible to do some initialization first and only connect the handlers if and when it succeeds. This can avoid the need to test that the object was properly initialized in the event handlers themselves: with Connect() they simply won't be called at all if it wasn't.
As a slight extension of the above, the handlers can also be
Disconnect()ed at any time. And maybe later reconnected again. Of course, it's also possible to emulate this behaviour with the classic static (i.e. connected via event tables) handlers by using an internal flag indicating whether the handler is currently enabled and returning from it if it isn't, but using dynamically connected handlers requires less code and is also usually more clear.
Also notice that you must derive a class inherited from, say, wxTextCtrl even if you don't want to modify the control behaviour at all but just want to handle some of its events. This is especially inconvenient when the control is loaded from the XRC. Connecting the event handler dynamically bypasses the need for this unwanted subclassing.
Last but very, very far from least is the possibility to connect an event of some object to a method of another object. This is impossible to do with event tables because there is no possibility to specify the object to dispatch the event to so it necessarily needs to be sent to the same object which generated the event. Not so with Connect() which has an optional eventSink parameter which can be used to specify the object which will handle the event. Of course, in this case the method being connected must belong to the class which is the type of the eventSink object! To give a quick example, people often want to catch mouse movement events happening when the mouse is in one of the frame children in the frame itself. Doing it in a naive way doesn't work:
- A EVT_LEAVE_WINDOW(MyFrame::OnMouseLeave) line in the frame event table has no effect as mouse move (including entering and leaving) events are not propagated upwards to the parent window (by default, anyhow).
- Putting the same line in a child event table will crash during run-time because the MyFrame method will be called on a wrong object.
However writing
MyFrame::MyFrame(...) { m_child->Connect(wxID_ANY, wxEVT_LEAVE_WINDOW, wxMouseEventHandler(MyFrame::OnMouseLeave), NULL, this); }

will work exactly as expected. Note that you can get the object which generated the event -- and which is not the same as the frame -- via event.GetEventObject().

So the morale of the story is: don't hesitate to use Connect(), it's much more powerful than static event tables which should be reserved just for the most simple situations when you don't need any additional flexibility and wish to save some extra typing, or maybe not even then for consistency sake.

Goals of wxWidgets

2006-12-22T16:58:00.000Z

A comment attached to the last post asked the question about what wxWidgets goals are. I was initially quite surprized because the answer was so obvious to me, but thinking a bit more about this I realized that we don't clearly answer this question anywhere in the public documentation and so for someone not following wx-dev mailing list the direction of wxWidgets development may indeed seem mysterious. To help with understanding it, I'd like to briefly explain where wxWidgets is coming from, what are the guiding principles for its development today and what I hope it is going to be tomorrow. Please note that, as anyone who does follow wx-dev would know, we don't always agree about everything and so what follows is just my personal point of view and while it hopefully does overlap with that of the others -- at least for the past and present parts -- I don't pretend to speak for everybody.

This disclaimer aside, let's start by looking at the current state of wxWidgets and how did we get there. On the negative, and often mentioned, side, it's an accretion of almost 15 years of development, by different people, some of which have stopped contributing to the project since a long time. So it is not surprising that there are some inconsistencies in the API (although we work hard on ironing them out) and some components (notably those whose maintainers have left) are not as good as one'd expect them to be. It is also true that compatibility with MFC seemed much more important in the nineties than now and this explains why wxWidgets has some superficial similarities to it, although it has never been nor designed to be, an MFC clone. So it's true that this long history resulted in some problems and we had to change quite a few things to fix them -- even the original name of the library turned out to be a bad idea.

However, on the bright side, not everything we did during these 15 years was a complete waste of time and, in addition to the accumulated historical luggage, everything that we did right is in the wxWidgets codebase too. And this is quite enough to allow people to create real life, professional complicated graphical cross-platform applications -- which is, to answer the initial question, what wxWidgets is about. To be more precise, the main goal is to allow the developers to do everything they need to do without resorting to writing platform-specific code: the "Write once, compile anywhere" principle. Of course, this goal is a moving target which can never be quite achieved because developers discover more and more things that they need to do with time as the new graphical environments introduce new standards (use of gradients and animations in the GUI was not exactly common when wxWidgets was started) but, still, I believe we're pretty close to it -- and getting closer with every new release.

So wxWidgets primary goal is to allow creating sophisticated portable applications without writing platform-specific code. This is not the only goal, of course, but it's the most important one and so trumps all the others. For example, wxWidgets could be more size efficient but this would be mostly important for toy applications and not for the programs which are themselves of reasonably important size. And so, while we'd be as glad to make wxWidgets smaller as anybody else, this currently has a relatively low priority because it's not very important from the main goal perspective. On a perhaps more constructive note, this also explains why do we consider the differences in behaviour of wxWidgets on different platforms important bugs: it's useless to have the code which compiles on all platforms if it doesn't behave the same everywhere during run-time.

But, to repeat, as important as this goal is, I think we're quite close to it and have been there since a long time. However other things could really be improved. Chief among them is the ease of use of wxWidgets: things have changed a lot since its creation and, in particular, modern C++ doesn't have much to do with C++ of the nineties. So it would be great to make wxWidgets evolve with the language and other standard C++ libraries. This would mean providing a more modern API, removing the need for memory management completely (this is very rarely a problem in wxWidgets even now, as most of the objects are owned by the library anyhow, but it would be nice to make this more explicit) and improve error handling by using exceptions. We should also rely more on the standard C++ library and Boost instead of implementing all various useful but not directly GUI-related classes on our own as we had to do in the past (as not implementing them would have conflicted with our primary goal whereas now, when such classes are available from elsewhere, it doesn't any more). This, and much more, is in our plans for wxWidgets 3.

There are certainly a lot of other tactical goals. The fact that I didn't mention at all fixing the bugs or improving the documentation doesn't mean that these goals are not important but just that they are obvious and I don't want to make this article even longer than it already is by stating the obvious. The point of this post was to just say that strategically, our main goal always was and remains making wxWidgets suitable for real-life portable applications development and, in addition, creating a new, modern, API for wxWidgets 3 in (hopefully near) future.

How to Contribute to wxWidgets Guide

2006-12-03T23:56:00.000Z

We often have the impression that wxWidgets could be so much better if only we had more time to fix the known problems with it, to implement all these exciting new features it still lacks or even just to fix the numerous old bugs. But unfortunately the time is always lacking (isn't it funny that you can regularly find jokes about 48 hour days in wx-related email since the beginning of the nineties?) and so many things remain undone. So the next idea, after failing to change the duration of the day, is to encourage more people to work on wxWidgets -- and it seems especially actual now that programming is becoming all about parallelization to take advantage of new multi-processor machines. And attracting new contributors does work rather nicely (better than trying to construct time dilatation machine, anyhow), for instance several new developers joined us relatively recently and brought us great things like AUI, custom comboboxes and almost all other new controls in the upcoming 2.8.0 release.

But we'd still like to attract even more! And maybe it's our own fault, after all, if people don't flock to wxWidgets development. We don't do much advertisement (real programmers hate marketing) and we don't even explain clearly how to become a wxWidgets contributor anywhere. Personally, as I want to keep my real programmer badge, I can't really address the former issue but at least I tried to help with the latter and so wrote this guide to explain how you can help with wxWidgets development. It is probably not as useful as it could be as it's hard for me to understand what questions and problems can a newcomer to wxWidgets (and/or open source development in general) have. But hopefully this guide is better than nothing at all and I'm looking forward to improving it in the future with feedback from the people it is really addressed to.

So thanks in advance for any comments about this guide! As for me, I'm finally going to log off and have a few hours of sleep after my 40 hours wxWidgets working day, safe in the knowledge that hundreds of new developers are going to join the project tomorrow ;-)

wxWidgets at Firebird Conference 2006

2006-10-27T08:54:00.000Z

The fourth worldwide Firebird Conference will convene at Andels Hotel in Prague, Czech Republic, on Sunday November 12. Notice one of the talks: "Developing Cross-Platform Applications with Firebird and wxWidgets" by Milan Babuskov. Be there!

wxwidgets.org website issues

2006-10-18T03:05:00.000Z

As mentioned in a comment on a previous post, the http://www.wxwidgets.org website is currently blank and has been so for a few hours now. Robin Dunn mentioned on the users mailing list that the likely cause is that vhost.sourceforge.net is currently down; alternate addresses such as

http://wxwindows.sourceforge.net/

Still appear to work.

Recently in the past there were also issues with speed of the site as well, possibly concerning sourceforge hosting; specifically image loading. Sometimes images would only load half the time. Images were shifted to and from an alternate server (run by Kevin Olliver) in an attempt to provide a temporary fix for the issue.

Right-To-Left layout (RTL) support in wxWidgets

2006-10-14T20:22:00.000Z

Here is some information about the support for locales with right-to-left (RTL) layout out in wxWidgets. As you probably know, RTL-support is required mostly of Hebrew, Arabic and Farsi. It has been decided that wxWidgets should follow mostly the Windows API and Windows approach for displaying RTL text and layout in applications. This approach is described in a document at MSDN here. In short, all coordinates for drawing and for window positioning are mirrored horizontally which means that (apart from bitmap mirroring) little has to be done at the user level. Also, the various native Win32 controls are modified to support RTL design.

This is different from what is done under GTK+, where no coordinates are mirrored. Instead, every app needs to mirror everything itself, even if the job of mirroring controls is mostly done within GTK+'s layout container automatically. As far as drawing within wxWidgets is concerned, coordinates are mirrored at the wxDC level in the GTK+ port. Some more information about GTK's RTL support can be found here.

I have added two screenshots from the popular FileZilla application running in the "ar_EG" (Egyptian variant of Arab) locale (screenshots in parts thanks to Tim Kosse). Since the tree control in the Linux screenshot is using generic wxWidgets code, this also demonstrates how drawing and scrolling is mirrored for user windows.

Below is a screenshot using wxWidgets and GTK 2.4.9.

Here is roughly the same screenshot using Windows 2000.

wxWidgets 2.7.1 released

2006-10-12T20:00:00.000Z

12th October 2006: wxWidgets 2.7.1 (a development release) is now available for download via http://www.wxwidgets.org/downloads.

The main changes since 2.7.0 are detailed below. We would be grateful for testing as we work towards 2.8.0 release within the next few weeks. However please be aware that 2.7.1 is not production quality.

wxMac defaults to using the more advanced Core Graphics implementation - this is a work in progress, and we would like to hear of any problems. You can edit include/wx/mac/carbon/chkconf.h to switch Core Graphics off.

Thanks,

The wxWidgets Team

Changes in 2.7.1
=================================================

All:

- Added wxDir::FindFirst() (Francesco Montorsi).
- Added wxPlatformInfo class (Francesco Montorsi).
- Added wxLocale::IsAvailable() (Creighton).
- Added Malay translations (Mahrazi Mohd Kamal)
- Added reference counting for wxVariant
- For consistency, all classes having Ok() method now also have IsOk() one, use
of the latter form is preferred although the former hasn't been deprecated yet

All (GUI):

- Support for right-to-left text layout (started by Diaa Sami during Google Summer of
Code, with a lot of help from Tim Kosse and others).
- wxAnimationCtrl added (Francesco Montorsi)
- Added wxAboutBox() function for displaying the standard about dialog
- Added wxID_PAGE_SETUP standard id.
- Added wxSize::IncBy() and DecBy() methods.
- Added wxTextCtrl::IsEmpty()
- Added file type parameter to wxTextCtrl::LoadFile, wxTextCtrl::SaveFile for
consistency with wxRichTextCtrl.
- wxRichTextCtrl: fixed range out-by-one bug to be consistent with wxTextCtrl API,
fixed some attribute bugs and added wxRichTextStyleComboCtrl.
- Added wxWindow::IsDoubleBuffered()

wxMSW:

- Implemented wxComboBox::SetEditable().
- wxSemaphore::Post() returns wxSEMA_OVERFLOW as documented (Christian Walther)
- Fixed a bug whereby static controls didn't use the correct text colour if the
parent's background colour had been set (most noticeable when switching to a
high-contrast theme).
- Respect wxBU_EXACTFIT style in wxToggleButton (Alexander Borovsky)

wxMac:

- Add parameter to the --enable-universal_binary configure option for the path
to the SDK.

wxGTK:

- Automatically use stock items for menu items with standard ids.
- Setting cursor now works for all controls.
- Implemented right-to-left support
- Implemented left indentation and tab stops support in wxTextCtrl (Tim Kosse).

wxUniv:

- Added wxTLW::UseNativeDecorations() and UseNativeDecorationsByDefault()

Towards quality in wxWinCE 2.8

2006-10-11T10:17:00.000Z

The most mature ports of our toolkit (wxGTK, wxMSW and wxMac) are nearly equally advanced in terms of features. The development on them is "easy" - they all have the same screen sizes, keyboards, pointing devices, and sounds so once a wrapper around their native API is in place, the ports can share a common wxWidgets infrastructure for events, placement of controls etc.

A few releases earlier we started work on a new family of ports that are increasingly demanded by the market: handhelds, phones and PDAS. See more about it at http://wxwidgets.org/docs/embedded.htm

wxWinCE is the name given to wxMSW when compiled on Windows CE devices. We have a dedicated section in our manual about this port, see: http://www.lpthe.jussieu.fr/~zeitlin/wxWindows/docs/wxwin_wxmswport.html#wxmswport

Are you a wxWinCE user? What do you miss most? When and how do you use #ifdef __WXWINCE__ in your code? Do you have some own improvements to this port? Please share any opinions and findings about the current state of the wxWinCE port on wx-dev and (for bugs and patches) the SourceForge trackers, and let's make it better together for future releases.

Google Summer of Code 2006: wxWidgets projects summary

2006-10-10T20:16:00.000Z

Google Summer of Code 2006 is over, and it's time to take stock of what's been achieved. We had nearly 20 proposals, and in the end three projects went ahead. All of the three have contributed useful code, and needless to say we're in awe of Google's programme that gave so much and asked for so little in return. Open source in general, and wxWidgets in particular, just took another big leap this forward this summer. Thank you Google! And of course a big thank you to the three students, and to others who submitted applications - perhaps they will be working on GSoC 2007. Meanwhile, there's still the page of project suggestions for people looking for contribution ideas.

Here then are summaries of the projects.

wxWidgets Package Manager

This project promises to make it easy for people to use the many available third-party wxWidgets components, which often have unique installation methods that take time to understand. What started off as one application has become a suite of three: wxPackageManager, wxPackager and wxp.

wxPackageManager is a GUI application that lets you browse local and remote package repositories, view a summary and details of the packages, and then download, compile, install, and uninstall them.

wxPackager is another GUI application that helps you create and edit a package description file, and upload the compressed package archive to a remote repository.

wxp is a command-line utility that allows you to perform all tasks exposed by the wxPackageManager and wxPackager GUI and also create and maintain repositories of packages.

Francesco Montorsi has already worked on valuable wxWidgets enhancements, but has excelled himself in this project, bringing a high standard of coding and attention to detail. It needed a fairly broad range of skills including knowledge of GUI design and implementation, network programming, multithreading, and XML. The project will make a significant difference to the ease of use of wxWidgets components when the package format is taken up by component authors. It’s doubtful if the package manager would have been built without the support of Google.

Links:

The CVS repository where the sources are hosted:
http://cvs.wxwidgets.org/viewcvs.cgi/sandbox/packagemanager

The server which hosts the latest release of the three programs:
ftp://ftp.wxwidgets.org/pub/utils/wxp/

Screenshots of wxPackageManager and wxPackager on Windows:
ftp://ftp.wxwidgets.org/pub/utils/wxp/wxpackagemanager.jpg
ftp://ftp.wxwidgets.org /pub/utils/wxp/wxpackager.jpg

The Package Manager on Windows XP:

Network class improvements

Angel Vidal’s project involved a range of fixes and enhancements to the wxWidgets network classes. These include unifying socket code for each plaform and rationalising common code; applying patches and updating the SourceForge trackers; adding proxy support for Connect() calls; improving UDP socket support; and testing on Linux 32/64, MSW and Mac OS X.

These improvements haven’t yet been incorporated into the main development branch, but we hope that after a little more work the result will be far better and more easily maintainable network code than in wxWidgets at present.

Angel's code is available in the SOC2006_SOCKET CVS branch.

Right To Left language support

As befits a framework developed by a group of people from many different countries, wxWidgets has long had facilities to help with internationalization and localization issues, but until now it had no support for RTL (right to left) scripts such as Arabic or Hebrew as we didn't have either the resources or knowledge of these languages necessary to implement it. Diaa Mahmoud Sami Abdel-Ghani started on the project to change this and to add full RTL support, including mirroring of the GUI elements, to the library. The project started well enough with the discussions of the API changes needed for this and, relatively soon thereafter, Diaa wrote the code to allow wxWidgets applications to show up correctly in Arabic locale under Microsoft Windows. Unfortunately, after the mid-term point almost no more work had been done until the very last few days of the program, and so the initial goals hadn't been fully achieved which led the mentor to give a negative final evaluation. Nevertheless, the project was far from being a complete failure as all code written by Diaa was integrated into the main wxWidgets sources and several people, notably Tim Kosse and Robert Roebling, were motivated enough by this to fix the remaining bugs and add RTL support for the GTK+ port.

So, while this project wasn't an unmitigated success from the student's point of view, it definitely helped wxWidgets as it has gained RTL support - probably imperfect but incomparably better than no RTL support at all. It wouldn't have happened without GSoC.

The RTL support is in CVS HEAD (2.7).

Beware: 2.7.1 Coming Tomorrow

2006-10-10T08:08:00.000Z

wxWidgets 2.7.1 will be released on Wednesday October 11 2006 (I thought the year was worth mentioning, especially for people used to our usual release schedules). So today you have the last chance to test your code using the latest cvs sources or the last daily snapshot and let us know about any new problems in 2.7.1 so that we could fix them before the release (and, of course, break something else to compensate for it).

Please pay attention to the documented incompatible changes in the beginning of docs/changes.txt, especially if you hadn't used 2.7.0 before.

Thank you for testing!

wxFileDialog and Windows Vista

2006-10-08T23:32:00.000Z

There are some changes regarding the native file dialog
in Windows Vista. Perhaps best explained by a shell
developer here: If one changes properties of the native
file dialog, one gets the "old" file dialog from Windows XP.

Here's an example of the difference: ("Old" is the first menu
option from the filedialog portion of the dialog sample, "New"
is the second.)

"Old":

"New":

The problem is that the dialogs sample uses
> dialog.CentreOnParent();
which causes Vista to revert to the "old" file dialog.

So, if you are using common dialogs just keep an
eye out if you customize it all; as even centering it
with its parent could change the appearance of it.
In fact, calling any wxWindow method can be
problematic as it can make the look of a common
dialog non-native, or it may not work at all (in
some cases on some platforms setting the
background color doesn't work, for example).

I posted on the mailing list awhile back,
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?5:mss:78283:200610:fgbndhmhiamfkklpjajh
but sometimes it is a lot better with pictures :D.

Also, it still happens with RC2, which is supposively
the last release before RTM (Release To Market),
so it is likely that this will stay.

For those to wish to interact with the new Windows
Vista file dialog API, they can use the IFileDialogXXX
COM interfaces. This also includes derivatives
such as IFileOpenDialog. Hopefully wxWidgets
won't end up having to support a seperate file
dialog interface; but then I guess one could
just pImpl it as well.

March of progress in action: wxAboutBox()

2006-10-08T19:43:00.000Z

Finally, 13 years after its beginning, wxWidgets has gained this mostly indispensable feature of any modern GUI toolkit: the possibility to show the standard "About" dialog with one line of code. As of today, wxAboutBox() function can be used to create a dialog box like this

or like that

or, if all else fails, like this

The generic dialog is not finished however as the best way to implement is seems to be using yet another new control: the hypothetical wxCollapsiblePane. The hope is to have it soon, finish wxGenericAboutDialog next, and release 2.7.1 immediately thereafter.

What would you like to see out of wxBlog?

2006-10-08T08:30:00.000Z

What would like to see out of wxBlog?

Current ideas are:
- Weekly recaps
- Just major events

Maybe this with personal commentary by
developers and former developers?

This blog was started not really out of
personal need, but more out of some of
the ideas on the developer's mailing list. I
(Ryan) will of course try to have a little fun
every now and then as well.

Feel free to comment!

Early October and a bit of September recap

2006-10-08T08:11:00.000Z

The wxDataViewCtrl class gotten some documentation.
wxDataViewCtrl aims to be a replacement for wxListCtrl
and wxTreeCtrl.

A standardized, and sometimes native, way for showing
an about dialog was added to CVS. The main way to do
this is through the wxAboutBox() function .

There is a bit of discussion over the status of the
SOC2006_SOCKET branch of CVS. This was the branch
started as part of Google's summer of code to make
improvements to the wxSocket APIs and implementation.

Changes to the wxIcon API on wxMac were also proposed
in order to better interact with the native Carbon API. Ports
are often inconsistant on the ease of use with
Native APIs; for example wxMac does not have a streamlined
way to interact with all types of window handles, such as
wxWindow::AssociateHandle; often times this is due to
the design of the Native API itself.

New classes for graphics were added, including wxGraphicsPath
and wxGCDC, in order to interact with APIs such as GDI+
on Windows and Cairo. There is currently no documentation
for the classes, however. The interface is available through
wx/graphics.h.

2.8 Release Schedule

2006-10-08T07:26:00.000Z

Welcome to the wxBlog!

There is a bit of a flurry on the development side lately
in an effort to get out a 2.8 release. According to a recent
thread on wx-dev (the developer mailing list), there are several
reasons for this. The most prevalent reason appears to be the
impending release of Leopard (or OSX 10.5), the next version of
the macintosh operating system. Stefan Csomor, the lead of the
mac port of wxWidgets, expressed that the mac port of
wxWidgets was not "up to snuff" enough for leopard.

A possible part of the reasoning is that wxWidgets
is included in Tiger (OSX 10.4), and is going to be included
in Leopard as well.

Several possible targets were discussed. Stefen expressed a
desire to get the final 2.8 release in time for Leopard,
possibly as soon as the end of the month (November 1). Some
others discussed an end-of-year target.

Currently discussions are underway for the release of 2.7.1, the
next development version.