Caribou and Text Predictor Input Mode

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:

Caribou with Accept key

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).

{“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.

SeriesFinale 0.2.1 version on Extras Devel

SeriesFinale seems to have had a good reception by the community. I didn’t imagine that such a simple app could please to so many people, or more particularly, that so many people would have issues with keeping up with TV series’ episodes. I’m happy for having written it.

SeriesFinale in N900 desktop

(SeriesFinale together with some of the community apps I use)

So, in the middle of last week I uploaded the version 0.1 to extras devel repository after solving the Debian package generation within the Scratchbox (Lizardo, from PyMaemo, helped me on this and wrote a helpful FAQ entry to the PyMaemo website). Still, the repository builder kept using Python 2.3 to build the package just like the problem I had on Scratchbox… tried again to push some changes and build it and still: fail! In the end I just gave up using CDBS for the package generation and edited the template of dh_make directly. Luckily, having a working Python setup script cuts part of the work (I like writing software, not packaging it!) and about the failed attempts, that’s what extras devel are for anyway…

Now version 0.2.1 is the one you can install and not call me ugly names afterwards ๐Ÿ™‚
This version should have been available since last week but apparently there was some kind of problem in the Extras Devel repository and some apps weren’t made available until yesterday.

SeriesFinale in App Manager

What does version 0.2.1 brings apart from working out of the Application Manager?

* Added mark all/none menus to the episode list view (suggested by Paco Zafra on the comments to my last post)
* The configurations folder is now stored under /home/user/.osso . My co-worker Calvaris suggested this to me since it will include the folder when you backup the device. And don’t worry with the current configurations you have now because I added a script to move the old folder automatically to the new location after this package is installed.
* Code improvements, among them, corrected local paths inclusion in sys path (for developing and running)

Episodes List Menu

For the next version I plan to enhance the visual of things a bit (how or what lies in my brain currently) and to introduce translation files.

Add your suggestions as comments to this post or sent them by email to me.

Have a nice weekend!

Going to Maemo Summit

In a few hours I’ll be flying to Amsterdam in order to attend the Maemo Summit 2009.

I’m also giving a talk about Porting GNOME Applications to Maemo Fremantle where I’ll talk about some common practices and decisions regarding the adaptation to Fremantle of applications that were designed to be used in the GNOME desktop. For these, I’ll use the experience of porting EOG and OCRFeeder to Fremantle.
I hope that it will help developers who are thinking on porting they’re favorite desktop applications.

If you want to discuss matters like “how do I adapt this behavior to Fremantle”, OCR, EOG or OCRFeeder for Maemo, just let me know and I’ll be glad to talk about these topics.

Hope to see you there!