GTK+ Multipress Input Method

I’ve done some more work on the GTK+ multipress input method, adding a GKeyfile-based configuration file, and some stability bugfixing, and Daniel Elstner has renovated the build files. The source code and packages for Debian Etch are online.

As soon as I figure out a good name that doesn’t use the (not ours to use) gtk/Gtk prefix, I’ll probably move the source into GNOME’s cvs.

Now we just need to add a way for applications to turn this off and on per widget, so that numeric-only entry doesn’t need multiple key presses.

(I also tried Movial’s input method, from Markku Vire, but I can’t get it to work. I commented about it there a few days ago but the comment hasn’t shown up yet.)

Going to FOSDEM

I booked my flights and hotel, so I’m finally going to my first FOSDEM conference, in Brussels, Belgium on the weekend of the 24th and 25th February 2007.

Technically, I am incredibly unproductive at conferences. I much prefer email for that kind of thing. For instance, I hate feeling forced to have instant opinions without first doing research and weighing pros and cons. Sometimes I want to put in-person conversations on hold while I do some fact-checking. However, actually meeting people is very good for development momentum, and it’s a chance to meet new European open source people and maybe drum up some more work for Openismus.

There are some GNOME activities at FOSDEM, but I’m not really sure what to expect. Dodji wants me to do a gtkmm talk, but I don’t really see the point. If you like gtkmm and C++ then there’s a lot of information about it out there already. I think conference talks should be for new things. So Dodji should tell us about Nemiver and what it needs from gdb, and I should maybe do a Glom status talk.

Linux-compatible wireless USB adaptor that I can actually buy? (part 3)

Information keeps arriving via the comments to my previous posts (1, 2), but there’s still no one good candidate for a currently-available USB (or even PCI) wireless card that “just works” with Ubuntu – or any Linux distro, I suspect. Linux Emporium have been updating their wireless adaptor page recently, and the current text backs up my suspicions. I hope they won’t mind me reproducing it here:


It seems that all good things come to an end, and we’re sorry to say that it looks like Ralink have stopped production of the RT2500 chipset – just as it has become well-supported by most important distributions, Debian, Ubuntu and openSUSE at least.

We’ve managed to keep things going so far, by searching out cards from various sources, but this has become too unreliable. Frustratingly, we know that Belkin have some of the older cards in stock, but they are unable to distinguish them from the new models, which have the same part number but a different chipset.

We’ve sourced alternatives, and as promised they’re now available. They have a new chipset, again Ralink, and the drivers have been been released by Ralink. Good for them! However, we’re in the situation we were with the RT2500 18 months ago, where the new chipset is not adequately supported in any GNU/Linux distribution. So we’ve done a lot of work and will be supplying a setup CD with each card. This will allow you to get wireless up and running until such time as the distributions support this chipset fully.

I’d love to hear about peoples’ experiences with that Linux Emporium script. It doesn’t sound like an easy thing to do.

Maemomm: Maemo for C++, with gtkmm

gtkmm is now available for the new Maemo 3.0 “Bora” version, as used on the Nokia N800 Internet Tablet. It’s in the extras repository.

There are also gtkmm C++ bindings for the Maemo UI (hildon-libs and hildon-fm) widgets, covered in the online maemomm documentation. Nokia tasked Openismus with updating these bindings for the N800 and writing the documentation, which was done mostly by Johannes Schmid and Daniel Elstner in the last few weeks of 2006. Of course, no applications use maemomm just yet, though gtkmm is already used enthusiastically on other embedded devices, and the demand for gtkmm on Maemo has been strong, so let’s see what happens.

It’s a slightly cut-down version of gtkmm for embedded devices, but most programmers won’t notice much difference in the API. I’d welcome patches to reduce the code size and memory requirements even more. It’s gtkmm 2.6 for now, but it looks like Maemo will update to GTK+ 2.8 or 2.10 in the near future. For the “armel” architecture that runs on the device, the (stripped) gtkmm library is 1.4M, which is a (small part of the) small price to pay if you prefer C++.

libgnomedbmm: Database UI widgets for gtkmm

Johannes Schmid and Armin Burgmeier have almost finished the C++ bindings for libgnomedb for Openismus, and the work so far is now in GNOME’s subversion repository, in the gnomemmm/libgnomedbmm module. There are already working examples in svn. This needs the latest version of libgdamm, which we have updated for the latest libgda API.

They will soon start on the documentation, to show how to use this stuff easily.

This work is for a company (Openismus codename: “The Austrians”) making some specialized embedded Linux equipment, using gtkmm for the UI.

A screenshot of a libgnomedbmm example:
libgnomedbmm_example_form

Linux-compatible wireless USB adaptor that I can actually buy? (part 2)

This is a follow up to my previous post: Linux-compatible wireless USB adaptor that I can actually buy?

I was really sure that the ralink-based ASUS WL-167G would be the one. But no, the ASUS WL-167G does not work in Ubuntu Edgy or Ubuntu Feisty (herd 2). In fact, the (open source) Ralink drivers seem to be a problem on most recent Linux distros. I’ll try compiling the drivers myself soon, but I want an out-of-the-box working wireless USB adaptor.

Based on the comments to my previous post, I now think that the zd1211-based MSI US54SE is the one that is likely to really work out-of-the-box. It’s available in Germany.

As far as I can tell, there is not one single Wireless USB adaptor that’s (widely) available in the USA that will work out-of-the-box with Ubuntu Edgy. All the models that have worked before now have seem to have new unsupported chipsets, without changes of model name.

Linux-compatible wireless USB adaptor that I can actually buy?

Has anyone bought a USB WiFi adaptor (54 speed rather than 11, ideally), in the last few months that actually works with Linux (preferably Ubuntu) without using the Windows driver via ndiswrapper?

There are several reports of adaptors that worked out-of-the-box but all those adaptors now seem to be sold with the same model names, but with different chipsets that don’t have Linux drivers.

Or even a PCI card? They keep changing those chipsets too.

New printer: Lexmark E120n

I got tired of my HP Deskjet 3650 just sitting there flashing its light, though it has a new ink cartridge [1]. Even when it worked, the page often slipped while (slowly) printing, and the page took a while to dry.

So I bought a Lexmark E120n. It’s a small cheap laser printer rather than an inkjet printer. Refreshingly, it’s mono only – black and white. I rarely print color and I don’t want to worry about whether I have enough color as well as black ink. The HP 3650 went through a phase of printing everything in green, which I won’t miss.

More significantly, it’s networked by default (wired, not wireless), though you can use the USB connection instead. After powering on, it connects to your network and prints out a page to show you what IP Address it is using. It has a web-browser configuration UI at that address.

Lexmark E120n printer

The CD includes Linux drivers, and the html documentation on the CD states that they officially support Debian, Linspire, Red Hat, and SUSE Linux. All the Linux stuff is in the “unix” directory on the CD, though the readme.txt file there explicitly states that the directory name and other mentions of “unix” should not imply support for crufty old UNIX – it’s just Linux that’s supported.

Even when connecting over the network, you need to choose the printer driver. The GNOME/Ubuntu printer manager didn’t list this model of Lexmark printer. Also the CD doesn’t have a bare .PPD file, so the “Install Driver” feature can’t work. There is a .deb file (.rpm too) but it contains lots of other stuff that I’d rather not risk installing if I don’t need to.

Googling told me that I could instead just choose the “PCL 6/PCL XL Printer” model from the “Generic” manufacturer, after choosing to add a Network printer of type “CUPS Printer (IPP)”, specifying the IP address, and that works fine. I’m using Ubuntu Edgy. Update: Instead of using the generic PCL driver, use the PPD file that Sven mentioned in the comments – the generic one has problems printing graphics. Also, note that you can get the IP Address printout at any time by pressing the green arrow “continue” key.

When it prints, it has that pleasantly familiar airplane takeoff sound rather than the wheeze of an Inkjet. It’s quiet when on standby, though I’ll keep it turned off because it probably draws lots of power.

[1] If the 3650 was sending any status errors over the USB cable, they weren’t showing up anywhere in the GNOME printer UI. I did try installing the HP Deskjet 3650 driver and tools on a Windows laptop but, after self-extracting the 3600_enu_win2k_xp.exe file, it just showed me an otherwise empty and untitled error dialog with the text “1158:”. There was a button on the dialog, but it was empty too. Which was, frankly, Windowstastic.

Irrelevant Update: However, I absolutely can not get the thing to work with my girlfriend’s old Windows ME laptop. Lexmark say that the printer is supported on Windows ME, but the installer refuses to run, saying “This intallation method is not supported on this operating system”. Installing the driver manually via the wizard, typing in the IP address, because browsing doesn’t work, leads to Windows telling me that the printer is currently offline. I’m waiting for the Windows installation to become so broken that it must be replaced with Linux.

Things I brought back from the UK

I spent a few days over New Year in the U.K., visiting my sister in Swansea (on the Gower, with beautiful moorlands, stormy cliffs and surfer beaches), friends in Oxford (much prettier than expected), and shops and friends in London.

Things we brought back from the UK:

  • Bagels from the Brick Lane Beigel Bake (various online pictures: 1, 2, 3). About £2 for a dozen, wonderfully simple and chewy. You could actually make a profit by flying these to Munich and competing against the boring 3-euros-or-so-each bagels that a few cafes, such as Coffee Fellows, all seem to get from one bakery. Or someone who knows how could just make proper bagels in Munich.
  • Alpen” breakfast müsli. Named after the alps, but not to be found in Europe. Actually, they started selling small German-language packets of the non-sugar version in upmarket supermarkets, but not the regular version, and not in big enough packets.
  • Garibaldi biscuits
  • Murray Mints, not my idea.
  • A furniture brochure from Unto This Last. They now box stuff up for sending outside of London, so we should be able to place a large order and have UPS collect it and ship it over to Germany, though that’s not really compatible with their ethics.

Creating GTK+ input methods

I have just implemented a GTK+ input method to allow input via multiple key presses, with a timeout, as on mobile phones.

(Update: here is a source tarball – improvements welcome. I’m now wondering how I can specify this as the default input method.)

I didn’t find any documentation about how to do this, but there are examples:

From these examples, I figured out the following, which I might try to get into the gtk-doc documentation later:

Functions that the shared library should export

The shared library must export:

  • im_module_init()
  • im_module_exit()
  • im_module_list()
  • im_module_create()

Updating gtk.immodules

The input modules must be listed in the /etc/gtk-2.0/gtk.immodules file, which is a cache of input modules information. Your Makefile should generate a new gtk.immodules file, using gtk-query-immodules-2.0, then install it.

Implementing a GtkIMContext

You must implement a GtkIMContext, an instance of which will be returned by your im_module_create() function.

Though most GObjects would have a *_get_type() function that calls g_type_register_static(), input modules need a *_register_type() function that takes a GTypeModule, which it provides to g_type_module_register_type(). This *_register_type() function should be called from your im_module_init() function. This means:

  • You can’t use the G_DEFINE_TYPE macro.
  • You can implement a *_get_type() function that just gets the GType if it has been registered by your *_register_type() function, but which fails otherwise. This seems to make if difficult (maybe impossible) to implement a GtkIMContext which is both directly usable and which may be a base class for other GtkIMContext implementations.

For “table-based” input methods, you can just derive from GtkIMContextSimple and call gtk_im_context_simple_add_table() with your table array, which specifies which sequences of characters can be used to specify an actual output character. When entering one of these intermediate characters an underline indicates that the user is in compose mode. Pressing the right arrow, or pressing a non-relevant character, accepts the displayed character. For instance, see the Tigrigna-Eritrean input method from GTK+, or the Esperanto input method in gtk-im-extra.

GtkIMContext has several virtual functions that you may want to override. These are not documented, but you can at least see their signatures in the GtkIMContext header file. The most important ones seem to be:

  • filter_keypress: This can emit the (undocumented) “commit” signal, sending a string when composing has finished, resulting in a character, and it can emit the “preedit_changed” signal, which will cause your get_preedit_string vfunc to be called.
  • get_preedit_string: This returns a string to be shown to the user, to indicate what character would be used if it were accepted. This can use Pango to show the pre-edit UI, such as underlined text to indicate a possible character.