As mentioned in my last post, Edu the mighty Cuban and I have been playing with the Kinect and developed an interactive installation for Igalia‘s 10th anniversary party using OpenFrameworks. (By the way, some people asked me for that application’s code so yesterday I cleaned it and it’s available on Gitorious)
OpenFrameworks offers a number of functionalities either from its core libraries or by means of add-ons and indeed there is an add-on that wraps libfreenect, the Free Software library that allows to control the Kinect.

Using OpenFrameworks was easy, it makes it fast to start developing with it but in many aspects it’s completely different from the way we’re used to work on GNOME. We are used to have single, independent libraries that do one thing and do it well and are used as needed by application developers, for example, do not include a sound library if my application is never going to use it.
Having modules such as GTK+, Clutter, Cairo, GStreamer, etc. already gives us flexible ways to develop certain parts of applications similar to the demo mentioned before: we just had to draw the fish using Clutter/Cairo, implement their behavior and show the Clutter stage. Of course we also would need a way to control the Kinect and it would be really nice if it could offer us an easy to use API for those familiar with GLib…

Ladies and gents, we give you… GFreenect

GFreenect is a wrapper for the Freenect library written using Glib in order to control a Kinect device and make it easy to use with GNOME technologies.
It doesn’t simply wrap the Freenect library but also offers ways of using it that are familiar to you if you have developed something using other GNOME libraries.
One example of this enhanced functionality is that we focused on offering an asynchronous API (although there are some synchronous alternative methods as well). Another example is that when setting the device’s tilt angle, a signal will be emitted when it has finished setting the angle, since it might be useful for some applications.

One of the purposes of having it written with GLib is the GObject Introspection capability. This allowed us to include an example application that controls the various features of the Kinect and was written in Python effortlessly. A screenshot of this app is shown below:

And that’s it! You can find the code for GFreenect in Gitorious (including documentation for this 0.1.2 version). Bear with us if you find some bugs, it is fresh out of the oven.

We hope you find GFreenect useful for your projects and please give us feedback if you find some issues or have any good suggestions.

After more than 4 months, I am finally releasing OCRFeeder‘s new version (its last release was in August, just before the DesktopSummit).
The reason for the delay, apart from some vacation in Berlin and Portugal and being busy in Igalia, was that this release brings deep changes internally.

The big issue

The problem with developing such an application from scratch in just a few months and worrying about writing a thesis is that you don’t care much for design and performance. So from 2008 until now, OCRFeeder has suffered a big problem related to memory consumption: depending on the number of images loaded and their size, it would create a reviewer (this is what I call the place where you do stuff on the images) per image and those would remain in memory, eventually crashing.
I assumed that since nobody complained about that for so long it was probably because people made a simpler usage of the application and didn’t use it for full books but now it seems that some institutions are interested in OCRFeeder and there have a been complaints and bugs filed (gb#637599 and db#646605).

This was fixed by having only up to 5 instances of reviewers. When selecting a new image, it will drop the oldest reviewer and have this one added to the cache. It gets a bit slower to select a new image but the trade-off is worth IMHO. In future changes I’ll probably make the number of reviewers configurable in some way.
Each of the content areas now also shares an editor instance instead of each one having a dedicated one.

I was able to load more than 500 images of ~4.5 Mb each and it was still usable so hopefully this will improve the experience for users who had these problems.

Other changes

Another change is that now OCRFeeder stores all its temporary files in a dedicated temporary folder under the system’s temporary folder (usually /tmp). By deleting this folder when the application quits it’s guaranteed that no temporary files will be left (as happened sometimes). Related to these changes, I’ve also decided to remove the possibility of choosing the temporary folder. Supposedly Python will already know what’s the system’s temporary folder and having such an option would make it look like Windows software from 1998.

As usual, some code cleaning and bug fixing was done and I would like to thank the awesome GNOME i18n team and everyone who sent their contributions.
Thanks to my friend Berto you can also expect an OCRFeeder Debian package on a repository next to you soon.

For a more detailed list of changes, check out the NEWS file.

Source Tarball
Git
Bugzilla

As promised before, here is the first release of SeriesFinale for MeeGo Harmattan.

This summer Micke Prag, a fellow programmer from Sweden contacted me because he was starting a port of SF for Harmattan. By then I still didn’t have an N950 because of having missed the deadline for the first developers program. Later, when the second developers program was launched I managed to finally get one. At that point, even though I already had my Samsung Galaxy S (yes, with Android) I still wanted to have a port of SeriesFinale as I had received many emails asking for this port so I started from Micke’s code and finally here it is!

The Harmattan port

Maybe it is something obvious but this version is not written in PyGTK/PyMaemo. It uses part of the “old” Python backend that was changed to play well with the new UI code written in QML.

Yup, after some months, here is a new version of SeriesFinale.

This new version doesn’t have many new features but brings an important one related to my previous blog post: the context menu.
When long-pressing a show or a season, a dialog will be shown with some actions. On the show’s context menu (or context dialog?), the user can update it, delete it, view its info or, more importantly, mark the next episode to watch as watched. On the season’s context menu, it can be deleted or, as many users have requested, mark all episodes.

Here are a couple of screenshots:

Of course that by only seeing the screenshots you don’t get the same feeling has when you quickly open the dialog and mark the next episode to watch so give it a try.
It it already in Extras Testing and if it works well for you, please vote for it to get into Extras.

The Future

This summer I bought myself an Android phone. That’s right, because of pure curiosity and with the help of Nokia’s decisions regarding MeeGo, I bought a Samsung Galaxy S.
I’ve been using it ever since as my main phone but I didn’t want to leave SF unattended yet. There are a couple of things more that I want to do and I’ll keep an eye on the download statistics to try to guess how many people is still interested in this app.

I haven’t yet found a full replacement for it on Android. I’ve installed a few apps that either don’t work well, require login or are bloated with features making it harder to use so I don’t know if I’ll end up contributing to some FOSS one or developing an official port of SF. Do you think that developing an official version for Android makes sense?
Also, people have asked me for a Symbian and Blackberry versions of it but I just don’t own any phone with these systems.

As for SF on the N9/N950, a release could be out there soon so stay tuned.

Yesterday was a holiday so I got some time to hack a bit in SeriesFinale.
One of the things I wanted to do was to have a context menu for shows and seasons. Something to apply individual actions like deleting, updating, viewing information, etc when there is a long press on a tree view’s item.

In Maemo the way to do this is to use the TreeView’s tap_and_hold_setup method but the problem is that I hate how this context menu is implemented: I have accidentally deleted stuff because of this menu. Can you think of a less intuitive widget for a touch screen? One that shows below your thumbs, only while you’re touching the screen and triggers some action when you lift it.
Instead, I wanted to show a dialog with the different actions so users could easily know what their doing.
Also, the fact that the API only allows me to use this long-press action to trigger a menu widget doesn’t seem like the best design…

Because of this I decided to implement a TreeView’s subclass that makes it better!
In my opinion, the way to implement this in the TreeView is to treat it like any other functionality: emit a signal when it occurs.

Though it wasn’t difficult, I thought the job would be easier. I had already implemented the “long-press” signal emission but the “row-activated” signal kept being emitted as well. Contrary to what I thought, re-implementing do_row_activated didn’t do it so I had to take a look at the GTK+’s source and though the row_activated method is indeed the one that emits the signal, there is also a “hildon-row-tapped” signal being emitted from the button_release_event. I don’t know if this signal is related or if it is the Python bindings fault but I had to prevent the “row-activated” signal from the mouse_released_event method in a hackish way…

Finally, when running the dialog, the application would freeze and not respond after this.
It was related to the emission being done from the timeout callback which, without having the time to look further, smelled like some race condition so I had to wrap the signal emission with the threads_enter/leave.
After this, everything worked well.

Like the “row-activated”, the “long-press” signal gives the tree path and the column that was pressed. It is emitted after pressing for 0.5 seconds and is cancelled if meanwhile the user moves the finger more than 25 pixels. These values are completely arbitrary and have just worked good enough for me. Of course you can easily change them.

And that’s it. I’ve called it EnhancedTreeView and if you want to use it in your Maemo application go ahead and copy/tweak the file (it has less than 60 lines).