Tag Archives: Ubuntu


Maliit Keyboard Improvements

On Friday I pushed 194 commits to the Maliit Plugins repository, adding new features, bugfixes, cleanups and tests to the Maliit Keyboard. This is some of the work Openismus has done for Canonical over the last few months which we are now allowed to upstream. This includes hard work by Michael Hasselmann, Krzesimir Nowak, Jan Arne Petersen and Jon Nordby.

Our work on the underlying Maliit Framework for Canonical was published upstream as we did it. We believe we’ll be able to upstream more of our Maliit Plugins work in the future.

Versions of these Maliit Plugins commits were published a few days ago in the Ubuntu Phablet project’s maliit-plugins Launchpad/Bazaar repository. It also contains commits (not by us) on maliit-plugins’ Nemo Keyboard, mostly for integration with the Ubuntu Touch platform (and its use of Android’s Surface Flinger). The recent Ubuntu Touch preview is using a version of that Nemo Keyboard, though we believe that’s meant as a temporary solution. A properly integrated Maliit Keyboard should behave significantly better.

Anyway, these commits add these features to the Maliit Keyboard:

  • Auto-capitalization.
  • Styling, such as a black underline for the current word and a red underline for a word with an error, though its up to the toolkit exactly how it shows this.
  • Word prediction, error correction, etc are now available when editing previously-entered words, instead of just the next word, taking into account the surrounding words.
  • Users can add words to the dictionary with a long press on the space key.
  • More settings to enable/disable auto-capitalization, auto-correction, word prediction, error correction, audio feedback and whether the word ribbon should be disabled in portrait mode.
  • Applications can specify text and icons for actions keys, such as Done, Go, Login, etc.
  • Keyboard themes can now specify fonts.

The maliit-plugins NEWS file gives more details.

Many of these features were already in the old MeeGo Keyboard (used by the Nokia N9) which had to be dropped last year because of its libmeegotouch dependency and its need for proprietary plugins to achieve these features.

We hope to have all this in an official Maliit release soon.

Programming For Kids

I tried a couple of applications with my four-year-old son: Pictomir and MIT’s Scratch.

Neither seem particularly well maintained and neither are suitable for young children without lots of supervision. Pictomir is easier to get started with, but not easy enough. Scratch is probably more interesting to older children, though they’ll partly be learning about how software is still so often arbitrarily annoying, and I’d prefer that they were introduced via a better example. I’m very tempted to write something better.


Pictomir at first start up.

Pictomir leads the child through a series of levels, telling an R2D2 robot (Don’t tell George Lucas) to move around some isomorphic squares to paint some tiles. At the beginning the program exists and the child just needs to click the play button. In subsequent stages the child has to build part of the program himself, and then all of the program.

The available commands, at least at the start, are icons for left-turn, forwards, right-turn and paint at the top of the screen. These may be be dragged into the available boxes in the program at the right of the screen, though you can instead put them there by clicking to select and then clicking on the empty box in the program. However, the available commands are far away from the program where you must place them, so the child has to spend lots of time moving the mouse pointer back and forth across a wasteland of empty space.

I found an official Ubuntu package in the developer’s PPA. It was last updated to Ubuntu 10.10 (Maverick), but you can install it manually on later versions. All of its UI is in Russian, though you can ignore most of it because the UI is icon-based. When I built the newer code from source a few months ago, I think the UI was translated.

I guess that Pictomir was developed for a specific screen size and generally older PCs. It does not scale the playing area up, so the child has to deal with a tiny R2D2 on a tiny grid in the middle of wide empty space.

pictomir has a bare svn repository, though I can’t see how clean its commits are, and I don’t know if it’s still used. There are no commits since last year. My svn says that the svn format is too old to check it out, though I’ve checked it on on previous Ubuntu installations.

It’s website it quite awful (and only in Russian). I only discovered Pictomir thanks to commenters on Google+.


The Scratch UI has several problems that make life hard for the child:

Scratch, after creating and running a small program.
  • Scratch requires the child to cope with tiny targets (See Fitt’s Law)
  • Scratch demands the use of drag and drop. This is frustrating for normal users, let alone children, and really hard with some laptop touchpads or trackpoints.
  • Update: Scratch requires the child to understand the difference between left-click and right-click. Right-click brings up a help context menu, which just causes confusion.
  • Update: The tiny commands have tiny text edit boxes. Children have a high chance of clicking it instead of clicking the command block itself. This problem could be partly solved by accepting drags on the edit box.
  • Scratch requires the child to double-click (see below).
  • The commands require the children to read, but a subset of the commands could instead be respresented by icons. The words are particularly hard for beginner readers because they are written in such a tiny font.
  • To get started with scratch, you need to figure out that you need to double-click on the first program command to actually start your program. There is no simple run button. You can cause your program to be run by clicking the green Flag button, but that’s something you need to put in your program.
  • When you try to move a command around in the program, it moves the command and all subsequent commands, as a group. So moving just one command means moving stuff around and then moving some of the stuff back to where you started.
  • Your program moves the Scratch cat sprite around the canvas, but that canvas is tiny, and the sprite can move off screen. The only way I found to get it back was to double-click the set-x-to and set-y-to program commands. I can figure that out, but beginners will not.
  • When you’ve drawn all over your canvas, the only way to wipe it is to go to the Pen set of commands and double-click the Clear command.
  • The sprite moves far too fast for the child to understand the relationship between the commands and the motion, without someone explaining it. If the command says move-10-steps then I’d expect the sprite to visibly move 10 steps. Advanced users might prefer it to be faster and smoother, but the default should make things obvious.

There are some other strange things in the UI which are probably a side-effect of its eccentric (Smalltalk) implementation.

  • Scratch has a menu (well, an icon-menu) for changing its language, instead of just using the user’s regular language.
  • None of the UI elements (menus, tabs, buttons, file chooser dialog, etc) match other standard applications on the system.

I think Scratch could be really popular with younger kids if it ran on Android with a touch interface and with less text, maybe as a simpler version. But the developers don’t seem to have any interest in that – they seem to be working on a Flash-based version of Scratch for the web, which is unlikely to work well with touchscreens, even if they can get Flash to work on Android and iPhone (they won’t). And I have no interest in hacking on Smalltalk. There seem to be various programming-language-based forks of at least the underlying engine, but none seem to be successful.


Generating SPDX files with licensecheck

This week I had to provide an SPDX file to a customer. SPDX seems to be a way to describe the licensing of software components, to help with open source compliance. Here is an official example (though it is probably not up to date with the current SPDX specification).

However, there are no open source tools to create or edit SPDX files, so I created a little openismus-spdx-generator.py Python script that uses Debian’s licensecheck utility to scan a project and then outputs a skeleton SPDX file in RDF format. It is a quick hack with no real error checking and I have barely read the SPDX specification, so please do improve it.

My first impression is that SPDX is rather unwieldy. The RDF (XML) format is verbose and seems to focus on being a snapshot of software via checksums of all its source files, rather than specifying a particular version or revision of the software as a whole. I don’t see any attempt to list dependencies and their licenses. More strangely, it looks like the .XLS (Microsoft Excel) spreadsheet format is the preferred format, which sets off my corporate-drones-doing-painfully-silly-things-that-they-believe-are-normal alarm bells.

There are official Java-based SPDX tools to convert between the various SPDX formats, and maybe to validate SPDX files. You’ll need to build them with the ruby-based buildr build system. Then you are left with some .jar files that have to be run via “java -jar target/whatever.jar the-spdx-file” after setting JAVA_HOME correctly.  Java programs are hard enough to package on Linux distros, but I’m sure that buildr makes it even less likely.

Anyway, the tools crash for me on the provided example files. The git repository has no branches or tags, so it’s hard to know which version is supposed to work and I don’t have confidence that the specification, example files, and tools are in sync with each other at any particular time.

Most of the SPDX file contents will be the result of a scan anyway, so rather than demanding that source code is supplied to me with an SPDX file, I’d generally prefer that the software just had proper COPYING files and source code headers. That seems like an easier requirement to comply with.

It’s all a bit linuxfoundationy.

Online Glom: Deployment

Today I deployed the latest Online Glom (gwt-glom) on a new Amazon AWS instance of Ubuntu Precise, again connecting Apache with Tomcat. This time I took notes about exactly how I did it. I wonder if this is something that I should put in a Puppet configuration (I have never used Puppet).

It took me a while to figure this out last time, but now it’s clearer to me. However, I still don’t know how to avoid the need for the /OnlineGlom/ suffix in the URL.

Glom 1.22

I released stable Glom 1.22.0 a few days ago.

For easy installing, I also created a Glom 1.22 package for Ubuntu Precise, in the Openismus PPA. Ubuntu Precise normally has Glom 1.20. I wish there was some similar way to create packages for Fedora, or someone to do that for me.

Beside the multiple bug fixes, Glom 1.22 has a few new features:

  • Details: Foreign key ID fields: Add a New button next to the existing Find button.
  • Allow custom (not related) choices to be translated, with only the original text being stored in the database. This only happens when the choices are restricted, at least for now.
  • Related Choices: Default to showing the primary key but allow the field to be be other than the primary key.
  • Related Choices: Allow the user to specify a sort order.
  • Allow the database title to be translated.
  • Added command-line utilities to help with translation via po files.

Online Glom: Now easy to build

Building gwt-glom

At least on Ubuntu, it’s now easy to build and test gwt-glom. You can just do:

$ sudo apt-add-repository ppa:openismus-team/openismus-glom-unstable
$ sudo apt-get install default-jdk maven2 libjava-libglom-java glom-utils
$ git clone git://gitorious.org/online-glom/gwt-glom.git
$ cd gwt-glom
$ mvn gwt:run

This opens the GWT Development Mode GUI, which serves gwt-glom via jetty and lets you see it in your browser.

Chrome is the most likely to have the gwt plugin that you need for development mode, though it’s available for some versions of Firefox.

How we made it this easy

GWT projects, like other Java projects, typically use maven (mvn) for their build system. maven is nothing like autotools.

Maven usually downloads dependencies automatically, either from the central maven repository, from some (maybe private) other maven repository that you specify. This sounds unstable, but you specify exact version numbers, so you can be sure that your project will continue to build. So maven doesn’t have the separation of building and packaging that I’m used to in the C/C++/autotools world. It feels odd to me, but I’m going with the flow.

However, java-libglom uses JNI to provide a Java API around a C++ (libglom) API, so it uses both Java (architecture-independent) and C++ (compiled and linked for particular architectures).

java-libglom installs a native shared libary. We packaged that for Ubuntu in our Glom PPA (stable and unstable) as libjava-libglom-java so you can install it easily.

java-libglom also creates .pom and .jar files (for the API, the sources, and the javadoc). These are in the central maven repository so maven can just download the .jar.

That libjava-libglom-java Ubuntu package also installs the .pom and .jar files that maven needs, but those are only useful for mvn-debian, which is apparently only useful for building other Debian/Ubuntu packages. There is no apparently no way to using mvn-debian’s local repository while also using the central maven repository for other stuff.

Java with autotools

By the way, java-libglom uses autotools, although the autotools Java support is barely useful and limiting, so we have custom rules for most stuff. However, autotools does let us generate the Java and C++ files from swig, and build the native shared library. That seemed harder to do with maven, though maven would have made it easier to deal with the generated Java code.

I do like how maven just defaults to using your .java files, and test ,java files properly if you put them in the correct places. For instance, see the maven quickstart project.

Glom 1.20

It has taken over a year of hard work but Glom 1.20 is finally ready.

This is the most stable and most usable version of Glom yet, with a few new features, now using gtkmm 3. Here are some updated screenshots. The major changes:

  • Simplified main window.
  • Glom can now store and display PDFs. It can store any file format, though it can only display images and PDFs.
  • Print Layout: Major overhaul with improved UI and new functionality.
  • Related Records: Allow the developer to specify how many rows to show.
  • Choice drop-downs can show more than 2 fields.
  • Choice drop-down fields are aligned.
  • Choice drop-downs can show related fields.
  • List columns have sensible widths.

Around 20 bugs from bugzilla were fixed, plus several more.There are over 30 tests that prevent regressions in mostly non-UI code. I still wish I could get some kind of automated UI testing working.

We have packaged Glom 1.20 (and several dependencies) for Ubuntu 11.10 (Oneiric) in the Openismus PPA. We might do something similar for Fedora.

Unfortunately, it will probably take a year for Glom 1.20 to officially get into distros such as Ubuntu (bug) and Fedora (bug) officially, and then they won’t deliver bug fix updates. This is partly due to lack of the volunteer packagers’ time and partly due to unfriendly distro policies towards applications. My only hope now is something like Glick.

Maliit: The only real on-screen keyboard

I recently pushed the Maliit team here at Openismus to tidy up the website, to make the current status clearer. Here is a summary:

Maliit is the only open-source input system that offers the features real products need, allowing on-screen keyboards for all the world’s languages. It is mature but it needs more work. This is the right project at the right time for various desktop projects to work together instead of having separate hacks that don’t please users.

Everybody loves the virtual keyboard on the N9, which Openismus worked on. That is the Meego Keyboard, which is built on the Maliit framework. It performs. It’s largely open-source, but it is fine-tuned for the N9’s MeeGo 1.2 Harmattan. It has an unfortunate dependency on libmeegotouch, which few developers love.

The newer Maliit Keyboard does not depend on libmeegotouch, though it does depend on Qt and QML. With enough effort, the Maliit Keyboard could be as good as the MeeGo Keyboard.

The underlying Maliit framework API has been thoroughly tested and iterated by these keyboards and by other input methods, both open source and proprietary. It has had many contributors, has gained many regression tests, and is run by people who care deeply about quality.

Note that Maliit is not trying to be an on-screen keyboard for accessibility.


We’d like GNOME to allow use of Maliit so people are not forced to use the current Caribou keyboard that only works with GTK+ applications and doesn’t offer features such as CJK or word prediction. We know that GNOME doesn’t want a hard Qt dependency. Of course that would be silly. We do want cross-platform compatibility. We also think that this is a large problem space that GNOME cannot tackle alone.

That would need gnome-shell (or its St toolkit) to support GtkIMContext as Maliit uses it. However, the gnome-shell developers currently feel that any on-screen keyboard (or input method UI, I think) must be part of gnome-shell’s own source code, and can’t be a separate process. Even if caribou could be made to work with non-GTK+ applications, a gnome-shell dependency is an even bigger block to cross-desktop adoption than Qt. So I really hope that this hard problem can be solved, though I do recognize that it’s hard.

The IBus implementation in gnome-shell seems to be hitting several similar issues (1, 2, 3), impacting CJK users even without a virtual keyboard. When they are fixed, maybe Maliit will work better. Note that, though Fedora has replaced SCIM with IBus, neither are really an issue for the on-screen keyboard, because IBus doesn’t let you show windows such as keyboards. However, the non-UI engines in the IBus plugins could (and probably should) be used in Maliit plugins.

I have some more notes about the current gnome-shell virtual keyboard here.

Unity (Ubuntu)

We’d like Ubuntu to use Maliit. We don’t know of any problems with that now, though I guess this depends on the GtkIMContext support in Unity’s nux toolkit library. We will do some tests on the WeTab soon.

Update: We published some Maliit packages for Ubuntu Oneiric in our PPA and we were pleased to find that nux seems to support GtkIMContext so you can, for instance, use the Maliit keyboard in the Dash’s search field. There are a few problems (1, 2, 3) but they seem fixable. There are also some generic GTK+ problems, but these are not blocked by anything fundamental in Unity.

Update 2 much later: That must have been with Unity 2D, using Qt. Nux doesn’t have an input method abstraction as of right now, though it could.

Ubuntu currently ships Onboard, though that’s apparently just for accessibility.

KDE and Qt

We’d like KDE to use Maliit for their tablet efforts. The Maliit keyboards work today in Qt and KDE applications, though I don’t know if that means that they work in Plasma too. They have a Plasma keyboard (source code) already, and there seems to be interest in using Maliit instead of, or as a base for that. That would give it features that it apparently lacks, while also sharing the maintenance workload.