Hildonizing wxGTK

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

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!