Vimeo is one of the main video sharing places in the web and I thought it would be useful to develop a Grilo plugin to search videos on it.
Yesterday Juan committed the code which means you should now be able to easily search videos from Vimeo and watch them in your desktop using Grilo’s test UI. Here are a couple of screenshots:
I really like the way Grilo is going. Together with GStreamer, the effort needed to create and media player with sources such as your hard drive, YoutTube, Vimeo, Flickr, etc. is just minimum.
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:
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.
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.).
I have been working for the past months in Hildon Input Methods (HIM) and many things have changed in it (and many will) with only a target in mind: make the experience of typing in N900, physically or virtually, a great experience.
Still, one thing I dislike in HIM is the fact that it is semi-closed source. Now what’s this semi-closed source thingy? It means that some modules are open, others are closed (HIM is a complex project).
(this is not the project logo)
For the open ones, and have you failed noticing it, the sad truth was that they were updated from time to time. No open development was done… but this has changed!
Since last week, HIM’s open source modules are now developed “in the open”, using Gitorious (thanks to Kimmo)!
The modules are hildon-input-method and hildon-input-method-framework.
This constitutes another step of freedom inside Fremantle and I hope you enjoy it as much as I do!
In my talk in the Maemo Summit 09 I mentioned a way to follow the Hildon HIG in what comes to HildonAppMenu’s items’ availability.
As written on it, the HildonAppMenu shouldn’t have insensitive items. Items that are supposed to be dimmed, should be hidden instead.
Now if you’re porting an exiting GTK+ application, these will likely use GtkActions as they are a great way not to repeat yourself while defining and sharing actions for widgets.
So, a nice way to keep using GtkActions while not showing the insensitive menu items is to hide these using a callback triggered by the “show” signal.
So, for me and some other Igalians, today was the last day at GCDS.
I also gave an introduction to Hildon 2.2. On this introduction, I talked about how to use the new widgets introduced on Hildon 2.2 as well as ways of accomplishing the same functionalities when porting an application to Maemo Fremantle. To better illustrate this, I compared the EOG for Maemo with the desktop version.
And that’s it, I must say I really liked my first GUADEC and I’m willing to go for the next one!
Maybe I’ll be able to write some post-event posts to compensate the lack of blogging during these days.