Daniel’s Blog

It used to be the case that in order to change the input method used by GTK+ applications, you had two options: Change the global default input method by editing some configuration file. Or use the Input Method context menu entry of some text widget every time you want to use a different input method. And even though it’s in a context menu, until recently the setting applied to all text input widgets of an application.

Last month, an xsetting was added to GTK+ which allows one to change the input method on the fly desktop-wide (bug #502446). And yesterday, a patch landed in GTK+ trunk which adds an "im-module" property to both GtkEntry and GtkTextView (bug #450716), in order to allow applications to assign non-default input methods to selected widgets.

Although not generally useful, this new capability can sometimes come in really handy as demonstrated by this tiny test case. As can be seen in the screen shot, the second entry is preset for the input of IPA symbols.

C++ programmers rejoice! I finally finished converting the Clutter tutorial written by Murray Cumming to C++ and the Cluttermm API. From the introduction of the new Cluttermm tutorial:

Cluttermm is a language binding for C++ on top of Clutter. It has the same functionality and concepts as plain Clutter, but provides C++ programmers with an interface that makes use of language features and common concepts of C++, such as static type safety, class inheritance and (optionally) exception handling.

Both the C tutorial and the new C++ one have been updated for the Clutter 0.9 API currently in development, which will eventually become 1.0. Therefore, this tutorial isn’t final yet and some of the examples still have quirks, but they all build fine. Right now, it only works with Cluttermm trunk, but a development release of Cluttermm 0.9 can be expected soon.

Better late than never. GTK+ has supported loadable input method modules since the beginning of the century. However, how to actually implement a custom input method and make GTK+ use it has never been documented.

So, if you ever wanted to implement your own GTK+ input method (say, for example, one that completes words from a dictionary like it works on a mobile phone) but have been put off by the lack of GtkIMContext documentation — there you go. The patch is waiting at bug #563994, for early approvers.

It would be nice if there were a non-hackish way to reduce the GTK+ documentation build times, by the way…

The project I’m currently working on required me to make some improvements to gmmproc, the code generator used by the gtkmm project. In my current work it’s occassionally necessary to wrap enumerations that don’t follow the consistent naming scheme of GTK+ we take for granted nowadays. This is how the enumerations look like:

• FOO_THIS,
• BAR_THAT,
• FUZZ_THERE

That should of course be:

• MODULENAME_FOO_THIS,
• MODULENAME_BAR_THAT,
• MODULENAME_FUZZ_THERE

Ideally, this would prompt a patch to the upstream code. But it’s not always possible to change upstream API, and even if it is you sometimes just don’t have the time for the bureaucracy involved and only want to get your code to compile for now.

But the code generator didn’t like the idea at all. The Perl script that gathers the enumeration definitions from the C header files even went into an infinite loop. I fixed that, but then it turned out that the enumeration parsing module of gmmproc unconditionally stripped everything up to and including the first underscore in every enumeration constant. The result looked like this:

• THIS,
• THAT,
• THERE

Ugh. Well, this prompted me to change the behavior of the enumeration parser to only strip the prefix if it’s actually common to all constants defined in an enumeration. It’s been a long time since I last dipped my feet into Perl, but it seems to work now. The new code is available from glibmm CVS, including the earlier branches from glibmm-2-8 onwards. I do hope it doesn’t break anything.

In order to actually prefix the enumeration constants in the C++ code, you can use something like this:

• _WRAP_ENUM(SomeType, ModuleSomeType, , s#^\b#MODULE_#)

You could even give the C++ constants the same names as in C, which would in many situations be the most appropriate scheme since we use namespaces instead of module prefixes in C++. The resulting shadowing could lead to problems though if C and C++ code is mixed. Your mileage may vary.

Tonight I had to move two project directories from a public Subversion repository over to a private server. Usually, to do this you’d dump the whole thing with svnadmin into one flat file and load it again at the new location. But to run svnadmin you need shell access to the Subversion server.

However, given that there are lots of tools around with names like cvs2svn I figured that something similar might exist for plain svn to svn migration. So I tried my luck and googled for “svn2svn”, and behold — I struck gold. It’s a hack and puts a quite heavy load on the server in order to retrieve the difference of every single revision to the next. But it worked like a charm:

• mkdir tmp; cd tmp
• svn mkdir http://destination/directory
• ruby svn2svn.rb http://source/directory http://destination/directory

That’s really all there is to it. The project directory is now at its new location, and has its history preserved. Many thanks to choonkeat for sharing his work!