I am in to the second hour of watching Firefox for Android compile, and I thought it would be a good chance to test this blog of mine. It has been relentlessly hacked for over a year until I decided to move it to wordpress.com and be done with it. I need to follow up with progress posts about Firefox mobile accessibility, and fanboy posts about GNOME (it sucks that I am not going to GUADEC this year).

Hi again. Remember my first post to Planet Mozilla? I hope not. Sorry for the male enhancement pills spam. Please stop contacting me for orders.
I am in Toronto right now, spending a week with Mobile folks. It has been about 6 weeks since I started working on a mobile extension, and the list of dirty tricks we employing to get things done is growing. Some of these hacks are there because there is no alternative, and some are there because I just didn’t figure out the right way to do it.
Here is a short list:

Gestures

I reinvented them, poorly. Our extension relies heavily on the ability to support a rich set of multi touch gestures. We have a hack, similar to how it was done in Touching is Good (I know!), where we swap out the callbacks in MouseModule and GestureModule for our own. This doesn’t seem right, for a few reasons. The main one being that this doesn’t seem like a real public API, and it will be broken sooner or later. The second thing is the fact that we are relying on shaky JS to re-interpret the platform-interpreted events. So maybe there is a better way to do things. The nsIDOMSimpleGestureEvent only serves us to a limited degree, I  think there is room for a more low-level multi touch event API that is similar to the Android one. Or maybe a comprehensive high level API with more event types.

Speech

This should probably be implemented natively and have multi-platform support. Right now, in Android, we are doing Javascript <-> js-types <-> jni <-> Java. What could go wrong?! But seriously, it is kind of ugly right now, but I would like to make our JS solution prettier and useful to other extension writers who want to tap in to Android’s API and services.

Security

The Mozilla profile directory in Android is not world-readable, presumably for good reasons. Our extension’s media files need to be world-readable so that Android’s TextToSpeech service could pick them up and use them as earcons. This requires an install and uninstall hook that uses Android’s Context.getDir to get/create a subdirectory in Firefox’s top-level app directory where we could copy over those media files for system consumption. Maybe this is the best way to do it… But I can’t imagine anyone being happy about an extension writing to that directory. Sorry!

–enable-accessibility

Our extension depends on accessibility being enabled at build time. Since I am getting some face time with folks this week, it seems like a good thing to bring up.

I am sure there are other horrible horrible hacks in there. But the list above is really what I needed to confess to. Thanks for empathetic attention.

Hello, strange new planet!
There have been countless Steve Jobs eulogies in the past week. Jobs is a complicated figure for me. He joins other historic American innovators such as Bell, Edison and Ford, who’s biographies celebrate the “land of opportunity” mythology, where anyone motivated could get ahead. On one hand they bettered society with affordable mass-produced technology, and on the other hand they employed aggressive business strategies, introduced bad labor practices, and ruthlessly quashed competition.
Dennis Ritchie passed away this Saturday. Eulogies are not competitions, obviously. But the contrasts between Jobs’s and Ritchie’s legacies are hard to ignore. Jobs introduced to the world iconic form factors, gadgets you could hold. But Ritchie and his co-inventors laid the foundation for modern software. That svelte iPad? Its operating system is 40 years old, Ritchie’s brainchild.
But along with the software, Ritchie and his friends introduced an entire philosophy. A philosophy that is just as seductive to an engineer as the latest Apple aluminium unibody product.
I grew up on UNIX. We had a machine at home with the hostname saris, Hebrew for eunuch. My dad taught me The Cool. Specifically the UNIX Cool of keeping it simple, less is more, and silence is success. It is this Cool that made me want to program, and it will outlast every fancy gadget.

[](http://www.flickr.com/photos/mostlypictures/6241535721/in/photostream)

After making a non-binding resolution to report my Caribou progress on a weekly basis, I flaked. Of course. But luckily Nohemi has picked up the slack and have kept you all up to date about the libcaribou powered GNOME Shell keyboard in her more binding GSoC reports. So no more architecture diagrams are needed, you all get the idea. But if you didn’t, let me make it clear: The goal of Caribou is to make it easy to implement new on screen keyboards where you would only need to provide the view, and libcaribou will be your model and controller.
It is better to admit now than later: I will not have the bandwidth to continue to work on Caribou as my time is slowly running out. So…

What we need:

• A maintainer.
• A GTK module, Nohemi is working on this, but we will need similar solutions for other toolkits and fallbacks (XIM?).
• Unit tests for the library – libcaribou is gaining features and getting complex. We need some tests here.
• More keyboard layouts/languages.
• More function keys for the switch scanning keyboard.
• Finer interaction modes:
• Modifiers, use latching and traditional key gestures with multitouch.
• Respect AccessX settings for sticky/slow/bounce keys.
• A more hardware-like interaction where keys will auto-repeat when held down.
• etc.

• … and automatically choose the right mode for the keyboard without comfusing the user.

• Revisit the “X adapter” and maybe use something more high level.

Anyway, plenty of exciting work. Are you at the summit, please find me if any of this interests you.