I am getting really excited about the Open Source Bridge conference in Portland next week. It feels like most Open Source meetups I have attended lately have been on the other end of the Atlantic. It will be nice to be in my element, for once. It will also be nice to meet cool localish people. I am planning to train down there and bring my bike. I hope to see you there!
I’ll be talking about inclusive design.

Hi again.
Since the last time I wrote to you, dear bloggy, I have been working a lot on Caribou, made a trip to welcome Jenny back from Haiti, and crossed the continent by rail.

Let’s talk about Caribou, so much has changed!

Antler

Antler is the Keyboard UI that is bundled with Caribou. It does not have the pretension of being ready for users any time soon, it is more a sample implementation of a libcaribou keyboard,and a place for me to try stuff out and see if it would work in our platform. You could follow Nohemi‘s progress to catch up on how libcaribou is being used to power the new GNOME Shell keyboard UI. With all that said, Antler is still kinda cool. Here is a crappy video of Antler’s touch keyboard in action:
[youtube http://www.youtube.com/watch?v=y2dJRC-YoIs&w=560&h=349]

Scanning Support

I redesigned Caribou’s switch support from the ground up with the goal of simple configuration. There is still plenty of more work to do, but after looking at commercial alternatives I feel like we could do a pretty good job. Here is me typing text solely with the right shift key:

[](/assets/uploads/2011/06/caribou_scanning.gif)

Input Method Support (bye AT-SPI!)

This is an experimental tangent, that might or might not be worth the time I spend on it. Recently Caribou master received GTK2/GTK3 input modules that perform DBus calls to the Caribou keyboard, and have it show up when and where it is needed. This has proven to be pretty tricky. I will hopefully follow up with a post about this, and some interesting hacks innovations surrounding these methods. Future work includes writing similar modules for QT3 and QT4. And having the keyboard emit key activation signals that the modules could use for inserting text instead of using XTest which feels so hackish and wrong.

That diagram I drew up earlier this week? I finished implementing it. It is in the badly named ‘geometry’ branch. I decided to take a day or two and redo some of the C stuff in Vala, with the hope that it will make life easier when I start adding a bunch of classes and create the DBus bits. I regretted it when I found myself hand editing vapi files and amending GIRs generated by valac, but all in all, I am pretty happy with the choice.
If I could be sentimental for just one paragraph and say that all the hard work folks have put into GObject introspection is finally paying off. Big time. Transitioning between all these different languages at will is really amazing. I think we are entering a perfect storm where we have an extremely competitive developer story. There is really nothing quite like this. Yay.
Since I spent this week shuffling deck chairs, I don’t have any exciting new visuals. Hopefully soon.

Hello again.
I didn’t get a chance to talk about my plans for Caribou in this little private SOC I am having here. Well here are two oil rigs is a diagram to illustrate it:

Caribou Daemon

The daemon, through AT-SPI and any means necessary figures out when a typing task is needed and activates the keyboard through DBus. When it does this, it provides as much information as possible regarding the text entry task: The location and size of the text area, the location of the cursor and the type of text expected (plain, email, url, number, full name). The daemon is written in Python, at least for now as Python is equipped with the best AT-SPI client library. The daemon has a relatively small body of code, so porting it to C is a worthy mission for some time in the future.

libcaribou

This is a library for keyboard implementors. It is written in C/GObject. It handles all common Caribou keyboard tasks such as:</p>

• De-serializing Caribou keyboard definition files into KOMs (Keyboard Object Model, I just made that up. You are welcome), with respect to the user’s XKB configuration and keyboard type preferences.
• Implementing defined keyboard behavior.
• Exposing the keyboard over DBus with interfaces known to the Caribou Daemon.
• Implement scanning.
• Do all the ugly X tasks, XKB, XTest, you name it. This could be replaces/supplemented with a higher level input method in the future.

Keyboard UI

This is the view for libcaribou’s model. It can be written in any language and toolkit that supports GObject introspection. The packaged UI is called Antler, and currently it is less than 200 lines of Python/GTK+. The idea here is that GNOME Shell (or anyone) could easily implement their own keyboard that can take advantage of Caribou’s facilities. If we pull this off well, keyboards will be advertising capabilities and co-exist, so the appropriate keyboard UI is invoked for the given task.

Thanks for reading! In a future post I will describe Antler and plans I have for it.