libxklavier provides the necessary methods but isn’t exactly well documented. It took quite a bit of trying and searching for apps that provide similar functionality. Eventually I found what I needed in gnome-control-center, file gnome-keyboard-properties-xkbltadd.c.

To get a list of languages libxklavier provides the method xkl_config_registry_foreach_language; and there’s also xkl_config_registry_foreach_language_variant that can be called for each language. What I didn’t understand first is that the TwoConfigItemsProcessFunc callback method sometimes gets called with config_item == NULL. It is important not to ignore these calls since these are the default layouts. Additionally, the country that you also need to build a proper locale string is conveyed in the parent_config_item.

Below is some sample code that lists all languages with their keyboard layouts. Beware that the language and variants are separated by a tab character in xkb_id.

#include <string.h>
#include <libgnomekbd/gkbd-keyboard-drawing.h>
#include <libgnomekbd/gkbd-keyboard-config.h>

char * description_utf8 (XklConfigRegistry * config_registry, const char * name)
{
    char *l, *sl, *v, *sv;
    char *v1, *utf_name;
    if (gkbd_keyboard_config_get_descriptions(config_registry, name, &sl, &l, &sv, &v))
        name = gkbd_keyboard_config_format_full_layout (l, v);
    v1 = g_strdup(name);
    utf_name = g_locale_to_utf8(g_strstrip(v1), -1, NULL, NULL, NULL);
    g_free(v1);
    return utf_name;
}

char * desc_to_utf8 (XklConfigItem * ci)
{
    char *sd = g_strstrip(ci->description);
    return sd[0] == 0 ? g_strdup(ci->name) : g_locale_to_utf8(sd, -1, NULL, NULL, NULL);
}

static void print_language_variant(
    XklConfigRegistry * config_registry, XklConfigItem * parent_config_item,
    XklConfigItem * config_item, void * data)
{
    char *utf_variant_name = config_item ?
        description_utf8(config_registry, gkbd_keyboard_config_merge_items(parent_config_item->name, config_item->name)) :
        desc_to_utf8(parent_config_item);

    const gchar *xkb_id = config_item ?
        gkbd_keyboard_config_merge_items(parent_config_item->name, config_item->name) :
        parent_config_item->name;

    printf("\t%s: %s\n", xkb_id, utf_variant_name);
    g_free (utf_variant_name);
}

static void LanguageVariants(XklConfigRegistry * reg, XklConfigItem * item, char * data)
{
    printf("Adding variants for language %s (%s)\n", item->name, item->description);
    xkl_config_registry_foreach_language_variant(reg, item->name,
        (TwoConfigItemsProcessFunc)print_language_variant, data);
}

int main (int argc, char *argv[])
{
    gtk_init(&argc, &argv);
    Display * disp = XOpenDisplay(NULL);
    XklEngine * eng = xkl_engine_get_instance(disp);

    XklConfigRegistry* reg = xkl_config_registry_get_instance(eng);
    if (xkl_config_registry_load(reg, TRUE))
    {
        xkl_config_registry_foreach_language(reg, (ConfigItemProcessFunc)LanguageVariants, NULL);
    }
    return 0;
}

On 32bit Windows and on 32bit Linux, a short in C++ is 16 bit long, an int 32 bit, long 32 bit and pointers 32 bit. On 64bit Windows short, int and long are the same as on 32bit Windows, but pointers are 64 bit long. On 64bit Linux, a short is 16 bit, int 32 bit and long and pointers 64 bit.

Comparison of data type sizes:

Note: I didn’t have a 64bit Windows machine to do these tests, that’s why there are some holes. The values that are there for 64bit Windows are from the documentation; all other values were retrieved experimentally.

A little bit of googling revealed that this is a bug that is known for a long time; there are several bug reports mentioning it. Eventually I found a pretty easy workaround: calling monodevelop with UBUNTU_MENUPROXY set to empty string makes the menu appear in the monodevelop window:

env UBUNTU_MENUPROXY= ./monodevelop-launcher.sh

Even nicer is to modify the monodevelop-launcher.sh script and set the UBUNTU_MENUPROXY there.

See also http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html

After a bit of googling around I found that the solution is really simple: just rename or delete the file

~/.config/menus/applications.menu

For some reason it had been created with a size of 0. As soon as I had deleted it the applications menu did show again!

At first I suspected a network problem, but my Windows PC was still able to load those pages.

I played around with the settings in /etc/nsswitch.conf. This made nslookup work correctly, but Firefox and wget etc still wouldn’t work. Very strange – you’d think that they would resolve a name in the same way as nslookup or host would do.

Eventually I found a solution: Disabling the DNS proxy in the Samba configuration file (setting ‘dns proxy = no‘ in /etc/samba/smb.conf) did the trick.

Today, while I was researching a different problem I found a solution: upgrading the Thinkfinger libraries from ppa helped. I added

deb http://ppa.launchpad.net/jon-oberheide/ubuntu jaunty main

to my /etc/apt/sources.list file and updated the Thinkfinger libraries, and it started working again!

It went pretty smooth; the only drawback was a problem with my graphics card Intel GM965: because there are known problems it is blacklisted, so Compiz doesn’t work anymore. And because of refactorings in the graphics driver some things don’t work so well anymore with the kernel included in Jaunty. But I got it working: I installed a newer version of the graphics driver xserver-xorg-video-intel. I edited the blacklist file and removed my graphics card from there.

A few days later I also changed my xorg.conf to use the UXA acceleration method. With this change Google Earth eventually works really well without displaying only flicker.

Another problem I had (again) was that Xorg was using way too much CPU. I remembered the problems I had after one of the last upgrades and removed/renamed my ~/.gconf directory. That solved the problem. It is annoying that this seems to happen after every upgrade.

I also had to update the Y-viewport positions in the ‘Place Windows Compiz Plugin’. While the X-positions had changed from being 0-based to 1-based with the last upgrade, the previous version was still happy to have 0-based Y-positions. But this changed now…

The good thing is that multi-monitor support really improved with Jaunty. The patches that I had to apply manually previously are all included. Nice.

On Mono however no dialog box shows; it behaves the same as when the user pressed ‘Ignore’. What’s worse is that it doesn’t display the call stack by default, even when run in debugger. This doesn’t give any hint if an exception happened.

But: some research showed that there is an environment variable MONO_TRACE_LISTENER that can be set that outputs the call stack to wherever:

export MONO_TRACE_LISTENER=Console.Out

In MonoDevelop you can set the environment variable in Project/Options/Run/General.

Some background information can be found in the Mono bug #317040.

And even better: if you create a .config file for your app and set the assertuienabled attribute to true, you get the same dialog as with .NET (discussion in bug #430477):

File app.config:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.diagnostics>
        <assert assertuienabled="true" />
    </system.diagnostics>
</configuration>

But there are still some differences to .NET: if the message box displays we don’t get a call stack in the output. I guess it might be possible to add another TraceListener (e.g. ConsoleTraceListener) that takes care of that.

IME (Input Method Editor) – allows input of complex scripts like Chinese.

TSF (Text Services Framework) – introduced with XP. Will eventually replace the traditional IMEs.

An application needs some extra code in order to make use of TSF. However, XP SP1 introduced an option on the OS level to make use of TSF even in non-TSF-aware applications. Vista extended that even more.

This means if an application allows to enter text with an IME it doesn’t say anything whether or not it supports TSF.

In one of our applications (Flex) Chinese IME behaves differently on Vista than other applications, e.g. it doesn’t show a horizontal menu that gives you choices. It works on XP.

Involved in the Chinese IME is IMM32.dll in Windows\System32 directory. It turns out that on Vista this dll is implemented using the TSF – it references MSCTF.DLL.

TSF has (at least) two sides: probably the most common use of the TSF interfaces is to implement a new text service that might provide an additional input method. There are some samples in MSDN that show how to do that.

The other side is the client side. An article in MSDN magazine suggests that you get automatic TSF support if you use plain edit controls, RichEdit controls, HTML editor controls, or the app is based on Windows Presentation Foundation. This means that most people don’t have to implement this side. The mentioned MSDN magazine article shows an example how to do it.

The TSF aware blog has some information and explains that you have to implement at least the ITextStoreACP interface.

One of the problems we’re having on an XP machine was that the Chinese IME didn’t work anymore after we went to certain dialogs. The user had to restart the app. I found a workaround: Add a DWORD value to the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CTF\KnownClasses\<RealClassName> = 1. You can find the real class name e.g. with Spy++ by clicking in the Note edit box. On my machine it’s “WindowsForms10.Window.8.app.0.2004eee”. Unfortunately it seems that the class name changes either with different builds or on different machines.

However, this workaround didn’t seem to work in all cases – don’t know why.

.NET has built in support for IME and supports it for all controls that are built in to .NET. However, ContainerControl (and derived classes) can’t receive IME input by default, so IME support is disabled for them. Before .NET 2.0 SP1 the Control.CanEnableIme property used to be internal, so there was no chance to make a control derived from UserControl (which derives from ContainerControl) IME-aware.

With .NET 2.0 SP1 Microsoft fixed this and made CanEnableIme protected so that it can be overridden.

Miguel Lacouture describes some of the things that are going on in a forum message. Microsoft describes this problem in a KB article (934197). However, the hot fix they are announcing seems a little dated…

After overriding CanEnableIme things work much better, but there are still the following issues open:

• On XP: With the QuanPin IME, if you go to a different field, it switches to English Input Mode (which you can see by the A in the QuanPin toolbar in the lower left corner of your screen).
• On Vista: With Pinyin it switches to English Input Mode when you go to a different field.
• On Vista: With QuanPin it displays the candidate window, but it doesn’t write any text to the field when you select a candidate.

Vista introduced a new kind of IME, Table Driven Text Service, that QuanPin 6.0 is based on. Michael S. Kaplan explains how it works in his blog.