I have been wanting to show how Caribou can be used with the Text Predictor Input Mode I wrote a while ago and finally today I took the time to do it.

Caribou with Text Predictor Input Mode from Joaquim Rocha on Vimeo.

Okay, the shortcuts  to accept prediction candidates or scroll through them can be changed into some that are quickly accessible.
With the changes I did to Caribou, one can even easily provide a special button, such as “ACCEPT”, like the screenshot below shows:

The changes I’m talking about and that you see in the video and the QWERTY keyboard layout I used can be found in Caribou’s bug #613229.

I wrote these changes because the current way of writing layouts for Caribou doesn’t seem very flexible nor appropriate for non programmers, in my opinion.
These changes drop the current usage of Python files with tuples as a way to configure Caribou’s layouts. Instead, json files should be used and more functionality that wasn’t implemented before is also possible with the mentioned patch.

Basically, instead of having either character keys or symbol, label pairs that Caribou understands, each key should be a set of attributes that define it, which Caribou then interprets accordingly.

For a basic key, all one needs to have is the value attribute, which can receive a string (for example a character) or the name of a key in GDK (you can easily figure them out from the GDK key syms file).
So:

{”value”: “a”} will create a key labeled a that inputs the character a
{”value”: “BackSpace”} will create a backspace key but labeled with “BackSpace”

You can override the label of a key using the attribute “label”, as:

{”value”: “BackSpace”,
“label”: “⌫”} will create a backspace key but labeled with “⌫”

Labels can use Pango Markup to change its text style, for example: {”label”: “<small><b>Small Bold Text Key</b></small>”, …}

A width attribute is also introduced and means the width relative to a usual key’s width. A width of 3 will generate a key that fills the space of 3 keys whereas 0.25 fills a quarter of a regular key’s space.

A key can be of a given type which indicates how it behaviors. There is 5 types of keys: normal, layout_switcher, preferences, mask and dummy.
A normal key type indicates it is a regular “you-press-you-input” key and is the default type, which is why it wasn’t specified in the examples above.
A layout_switcher key, when pressed, will change the keyboard sublayout to the one given by the value attribute (and must exist in the layout file), so, if we are in the “lowercase” layout and we want a key labeled “UP” to change to the “uppercase” layout:
{”label”: “UP”, “key_type”: “layout_switcher”, “value”: “uppercase”}

The preferences key type brings up the preferences menu.
A mask key means that you set a mask indicated by the value attribute when you press it. For the Alt key:
{”label”: “Alt”, “key_type”: “mask”, “value”: “mod1″} again, the “mod1″ is the mask name from GDK.

Finally, there’s the dummy key type which is used basically to set spacer keys and allow to separate some keys from others in order to improve visual grouping. Rows that don’t have the number of keys in any row (including dummy keys) will be centered horizontally.

These let you play with keyboards’ layouts and design any kind of layout in a flexible and easy way.

At the moment, the patch is still pending review. Let’s hope it gets a green light and is applied.

For those who didn’t notice, last week SeriesFinale finally got promoted to Extras which are very good news and now SeriesFinale 0.5 has been just released!

Why is this edition so special? Because it will from now on retrieve images for the shows and its seasons.
This morning I finally took the time to check how to retrieve those and I really like the way SeriesFinale looks like now. Of course, this means that the next shows update you do will start retrieving all the images for your shows and seasons which might take, let’s say, a while. Still, don’t worry because once it gets the images, next time you update, only the general information will be retrieved.

I’ve also fixed the slowness when panning the different content views. Panning should now be much more fluid.

Another good thing in this edition is that the tiny episodes’ checkbox still looks tiny but it’s in fact larger and this means you can much more easily tap on it to mark episodes.

Juan, the maintainer of the Diablo version and a colleague of mine at Igalia, sent patches for including the season number together with the episode number, so it shows like “2×05″ which is more useful than just the episode’s number.
He also pointed a bug when adding a show  manually, which got fixed for this release as well.

Here are a couple of screenshots showing what you’ll see soon (I just finished sending the packages to the server) in your favorite mobile phone:

SeriesFinale with shows' art

SeriesFinale with seasons' art

(I didn’t have time to update or integrate any translations in this version but I’m planning to have it done for the next one so I apologize for any inconvenience.)

I have just released OCRFeeder version 0.6.5!

Here are the main changes in this version:

* Importing PDF files is now faster
* The OCR engines manager dialog now allows to detect and choose to use system-wide OCR engines (this action is also used when the application is started with no engines configured)
* Multiple content areas in OCRFeeder’s canvas can now be selected using Shift+Click
* Introduces Ctrl+a shortcut to select all content areas in OCRFeeder’s canvas
* The Tools menu now has the new action “Recognize Selected Areas” which will perform the automatic recognition on selected content areas of OCRFeeder’s canvas

Also, a few bugs were fixed:

* Removed PDF files’ extension from the images generated from them
* Sorts images when adding them from a folder
* Selection areas are now getting selected after creating them
* Fixed problem when quitting the application

(You can also read the full list of changes)

Recognize All Areas action

You can download the new tarball from GNOME’s FTP or a Debian package from here.

I’d also would like to thank the GNOME i18n Team for their work translating OCRFeeder.

As has become usual every couple of weeks or so, I released a new version of OCRFeeder!

This is version 0.6.1 and the main changes this time are:

* Now you can increase or decrease the zoom using Ctrl+Mouse wheel. This kind of shortcut is well known in many GNOME applications and even I was missing it;
* Warning dialogs are now shown when something went wrong while opening an image;
* Fixed encoding problem when reading non-ASCII characters;
* Fixed error when configuring a new engine;
* Improved Debian package’s files (thanks to Alberto Garcia)
* Fixed zoom issues (sometimes the allowed zoom would not be consistent among tries);

It was a good week on OCRFeeder’s bug tracker, specially thanks to user Hank who reported important problems.

I am really glad about how OCRFeeder is turning out and I expect to make it even better with the help of its users, either by sending suggestions, reporting bugs or simply by using it you will be helping the project.

You can download OCRFeeder 0.6.1 tarball from GNOME FTP or optionally download a Debian package directly.

I was disappointed with the text completion provided by the N900 (eZiText) that, on top of that, is closed and I wondered if it was possible to have an Open Source solution to provide text prediction and completion.

I searched a bit and besides my original intentions of developing a library to search Free and Open Source dictionaries’ words from a prefix, I found Presage.
Presage is better than most text prediction systems I have seen out there because it really is text prediction, not text completion. This C++ library, retrieves words taking into account the surrounding text, not only the prefix or frequency of words. It uses a database representing N-grams that can be trained with more text; the more you train it, the more accurate it can be.

This means that is you type something like:
“I m”
instead of suggesting nonsense things like:
“I mouse” “I mother” “I market” or “I more“
it suggests something more like:
“I must” “I met” “I mean” or “I might“
The difference is obvious!

So I developed a little wrapper around Presage in C that provides a yet very basic API to get text completion. Then I created a GTK+ Input Method context to control the user’s input in regular GTK+ text widgets and used the wrapper to process the inputted text. I called it: Predictor Input Method (not very original I know…).
The result is that Predictor suggests you words, even if you type a prefix or not, and lets you accept the candidate word or scroll through a list of suggestions as you can see in the video below:

Text prediction in GNOME from Joaquim Rocha on Vimeo.

How to use it

The current key bindings are:

Ctrl+Enter -> Selects the current candidate
Ctrl+Up/Down -> Scrolls through the list of candidates
Backspace -> Deletes the character previous to the cursor and suggests again
Directional arrows -> Move cursor and discard suggestions

Who should use it

This kind of assistance technology can have many applications but the main ones are: the usage in small/mobile devices and the assistance of users with disabilities. Both have the same reasons behind: speeding the input and reducing failed characters, because the input required gets minimized;
Of course, you can as well use it in your GNOME desktop regularly for faster typing your emails, etc.

In the case of users with disabilities, a popup menu could be added to show a complete list of candidates and the bound fast-access keys.

Why is Free Software important in this

This is the kind of technology that everybody should have an interest in using a FOSS solution because of the obvious advantage that is developers from all over the world being able to modify it.
Suppose you’re creating a mobile phone and you choose a closed solution to provide text prediction for your phone. And then you find out you’re disappointing all your users from country X because that library you’re paying for does not support their language and the library owner is not interested that much in adding it. Now if you’re using an open solution, local communities from many places in the world can add support for their languages and your phone can have a better acceptance in places you hadn’t even imagined.

Software that reaches an international audience with different languages is software you want to have open.

How to get Predictor Input Method

You can find the Predictor Input Method’s source its Gitorious page: http://gitorious.org/text-predictor-input-method
Of course, you should also install Presage for it to work.

If you are not using GTK+ Input Methods then you can use the wrapper text-predictor.cpp which is not tight to the Input Method code itself. And of course, you can copy the little tricks used on the Input Method code and apply it to your source (like delaying the retrieval of the candidates some fractions of a second to not block the input, etc.).

Hope you like it.