Thoughts 'n Stuff

How we enable others to write 3rd party plugins with Maliit

We finally published a video about Maliit - an input method framework including a virtual keyboard - and 3rd party plugins. Kudos goes to Jon for making time for that.

This video highlights one of Maliit's key features: pluggable input methods which come with their very own user interfaces. The Chinese input methods show how Maliit offers support for composed characters. The video is proof that 3rd party development for Maliit (open-source and proprietary) is not only possible but also happening.

maliit.org states that "it should be easy to customize existing input methods or develop powerful new input methods, whether for profit, research or fun", we actually mean it.

The harder question is of course how to motivate others to actually get started on input method development with Maliit. For that, we have a multipronged strategy:

1. Provide sufficiently polished reference plugins that can show off Maliit capabilities but also serve as inspiration for new plugins (hence the BSD license for reference plugins). Our reference plugins are currently using Qt/C++ (Maliit Keyboard) and QML (Nemo Keyboard). We also have PySide support, but no one contributed a reference plugin yet. This gives choice to interested input method developers, and we think that's important. The reference plugins serve another role when it comes to designing new API: They become our testbed, allowing us to verify our API proposals.

2. Ship Maliit with a bunch of example plugins and example applications. None of them try to be complete. They are all self-contained though and usually show one feature at a time. This can be tedious to maintain, but we believe that examples need to stay small and focused, otherwise developers won't look at them.

3. Documentation that is easy to consume. Our documentation is not as concise and clear as we'd like it to be, but it's slowly improving. We also experiment with videos that can serve as an introduction to more in-depth (text) documentation.

4. Packages for most common Linux distributions. This one seems obvious, but sadly, it's quite a lot of work for us to keep up with it (and we already use automated services such as Launchpad and OpenSuse Build Service). In the hope to attract dedicated packagers we wrote down some packaging guidelines

5. An architecture that had 3rd party plugins and multiple toolkit support in mind from the start. The plugin developer facing API needs to be easy to use and clearly documented. This will be the focus of the upcoming 0.9x series.

We will demo Maliit @ FOSDEM 2012, hope to see you there!

Using MeeGo Keyboard from git on your Nokia N9

Usually AEGIS, the N9's security framework, protects system packages from being replaced. As such, files belonging to a system package can't be overwritten. And that's definitely a good thing, because otherwise each download from OVI store would put the user at a considerable risk.

Maliit is such a system package, but its flexible architecture allows for a creative way to replace the MeeGo Keyboard with a more recent version. This can be useful if you want to testdrive new features and to … nah whom am I kidding, it's purely for fun!

Be warned though, the following hack requires you to enable developer mode on your N9. Don't ever activate it unless you're absolutely sure what you're doing to your N9. It would be unforgivable to brick this beauty because of some misguided hack the planet attitude.

First we need to find a MeeGo Keyboard tag that will be compatible with the installed Maliit framework version on your device. Check that the output of

$ apt-cache showpkg meego-keyboard

matches the dependencies mentioned in the tag's Debian control file and the packages installed in your scratchbox ARMEL target.

Apply the community patch on top of the chosen tag. It renames the package to meego-keyboard-community and only installs the plug-in's .so file, together with a renamed CSS file (libmeegotouch requires that CSS file names match with library names).

This mean that we won't uninstall the regular package, as we still depend on most the other files that meego-keyboard installs.

Now build the Debian package. Copy it over and login to the device, then gain root access via devel-su. It's recommended to make a backup of /usr/lib/meego-im-plugins before installing the package.

After installing libmeego-keyboard-community, remove libmeego-keyboard.so from /usr/lib/meego-im-plugins, to avoid in-fights between the two plug-ins. Use

$ gconftool-2 -s /meegotouch/inputmethods/onscreen/enabled -t list --list-type string [libmeego-keyboard-community.so, en_gb.xml]
$ gconftool-2 -s /meegotouch/inputmethods/onscreen/active -t list --list-type string [libmeego-keyboard-community.so, en_gb.xml]

to activate the community plug-in. The language settings applets will most likely get confused, so be prepared that enabling new language layouts might only work directly via GConf from now on.

Gain user access and kill meego-im-uiserver. It should now load the new community plug-in. If you want to get the original MeeGo Keyboard back, uninstall the community package and copy the .so back from your backup. Alternately, you can try to reinstall it:

$ apt-get install --reinstall meego-keyboard

Have fun!

New features in MeeGo Keyboard

This week we published new features for the MeeGo Keyboard, including accent popups (activated through long-press on certain keys) and support for Chinese Input Methods. The latter still requires an IM engine that supports Cangjie for example to be really useful (not provided by MeeGo Input Methods).

Ubuntu users can easily test it out, as I updated the packages in the MeeGo Input Methods PPA. I also enabled all language layouts by default for those packages, as we yet have no real UI for the Desktop to control such settings. You will have to install the additional layouts package manually though (package is called meego-keyboard-zh-layouts).

One can switch to another language by swiping to the left or right (on the keyboard itself), which is admittedly a bit stressful with a mouse (and nigh impossible with touchpads!). It works quite nicely though when using touch screens. I am sorry for the strange transition animation, it apparently needs some adjustments for the desktop.

We'll also have some GNOME3-related news soon, so stay tuned!

Updated MeeGo Input Methods packages

I published new versions of the MeeGo Input Methods (framework and keyboard plugin) on the project's Launchpad PPA. It contains the API/ABI break that was announced in the beginning of this month.

At first I thought I would do this packaging only for others but I have to admit that I start to enjoy using my host system for input method development - it's really easier than having to use the MeeGo SDK or scratchbox even.

I also added some patches so that the on-screen keyboard docks itself to the bottom of the screen. For MeeGo Touch applications, focus widget relocation will work on the desktop now. If that's not enough for you then how about a slightly translucent keyboard background? For this to come true, you only need to modify the keyboard's SVG file, located at:

/usr/share/themes/base/meegotouch/svg/meegotouch-virtual-keyboard.svg

Search for this section:

<g id="meegotouch-keyboard-background">
  <g>
     <rect x="100" y="100" width="64" height="64"/>
  </g>

</g>

and add a opacity style property to the rect element like so:

<rect style="opacity:0.5;" x="100" y="100" width="64" height="64"/>

You need to restart the meego-im-uiserver process to see the effects though. I will explain the other theming possibilities in another blog post.

The packaging problems I encountered in my last blog post are also solved: A Launchpad PPA keeps all packages in one repository, so one needs to explicitly mention the Ubuntu version in the package names, otherwise they can easily supersede each other.

MeeGo Input Methods for your desktop

I've been working on the MeeGo Input Methods project (codename "Maliit") for nearly a year now. The project provides a pluggable framework for input methods. It comes with a reference plug-in for a multi-touch-capable virtual keyboard.

It had bothered me that, even though our source code was available at gitorious.org, there were nearly no contributions from the outside. I attribute that to the difficulties when it comes to compiling all required components, but also to the lack of perceived openness.

We now offer packages for Ubuntu, through the Openismus PPA for MeeGo Input Methods, thanks to the packaging efforts of Jon. This is an offer for those interested in developing input methods for MeeGo. It's not targeting end-users (yet?) - a virtual keyboard might not be useful on a desktop, unless you have a touchscreen.

We also have a public wiki and if you wish you can visit us in #meego-inputmethods @ freenode.net.

First Miniature .debs sighted!

Thanks to Mathias, Miniature is now suitable for debian packaging. He also uploaded a first test balloon which at least allows you to move pieces around. Feedback is of course more than welcome.

Personally I wish the board's cell size could have been made bigger, but 60x60 pixels is already the upper limit. It is now up to us - the Miniature team - to come up with clever techniques to make the board handling as finger-friendly as possible.

What to do if you do not understand Debian Packaging

Up until now I had only been a consumer of debian packages and had a mostly pleasant experience. Dependancy resolving works and apt-get & friends are reasonable efficient. If everything fails there is always apt-get source. So it was about time to get on the other side of the fence! However, simply searching for HowTos was already irritating enough =) Not that you wouldn't find any documentation, quite the opposite! You find way too many, many of them describing different ways of How To Do It Right TM.

The easy way perhaps is to just start with an already debianized project and perform an update of the sources. That got me to my first debian package quickly (copy this debian folder here, dch -i into a quick "edit-the-changelog" session, debuild the new packages, DONE!) but I didn't understand much at all . Then I thought I'd learn more by debianizing some toy code of mine. Since I was already using autotools it should have been straight forward - get everything created by a "make install" into a binary, or so. Well, I only got the executable included in the end =) The mysteries of the dh_* universe.

Then Daniel pointed me to the Common Debian Build System. It required even more reading (I managed to pick the director's cut, instead of the plot summary) but at least this beast called debian/rules was tame-able now!

CDBS is a true winner in debian maintainer land I guess. Though one detail kept me occupied, and that was how the call to "dh_install -p" didn't extract the appropiate files from my debian/tmp install folder for a multi-binary debianization. It wasn't a case of missing .install files, or misused globbing. CDBS simply doesn't pass the correct --sourcedir path to dh_install! If you don't know the conventions used by dh_* tools then you would hardly guess you have to use the DEB_DH_INSTALL_SOURCEDIR variable in your debian/rules file. But the truly great thing about CDBS is that you can lookup how it invokes dh_install (it's only Makefile magic, after all): fgrep -ri -- '--sourcedir' /usr/share/cdbs/1/rules/, and you'll soon figure it out.

Oh something that I personally found quite clever was the debian/rules shebang: "#!/usr/bin/make -f". I have called Makefiles from other Makefiles in the past but this solution takes the cake, unless of course you think "include /some/other/Makefile" doesn't look nice.

Other useful commands:

• dpkg-checkbuilddeps shows (developer) dependencies of the current source package
• apt-cache depends shows the dependencies of a package
• dpkg -L shows the files contained by an installed package.