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

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

Finally I could get a little time to finish SF 0.6.8 release.

In this release one thing I wanted to improve was the startup time. With the number of TV shows I have in my SF, it was taking around 25 seconds before showing me the list of shows. Part of this is due to the deserialization from the DB (no, it’s not using SQLite and I have no time to make the switch) which takes its time but also because it was attempting to sort the list of shows every time a show was added and it also took some time loading the shows’ covers from disk.
This fix was basically loading of the covers asynchronously and sorting the shows only after they are added to the tree view. It improved from 25 seconds to 12 seconds more or less.

While the shows’ covers are being loaded on startup or downloaded from the web, it displays something like shown on the following screenshot:

One of the features people like more is the display of the next episode’s air date. To improve this, I’ve added a small tweak to humanize the dates close to today so it displays “Yesterday” instead of “20 Jul”.

The covers retrieval was broken for a while and this is fixed too. What happened was that TheTVDB started redirecting images to a mirror and SF was not following redirected links… It should follow them now, so it is unlikely to happen again.
I’m also including the French translation kindly sent by David Landreau.

Other important improvements and fixes are:
* Fix deleting seasons;
* Add sorting options to the seasons view;
* Fix infinite loop when updating episodes (it happened when there were two shows with the same name);
* Consider next episode to watch only when it has an air date;

There are also some good news from other platforms’ ports. Nacho has created a branch where he is porting the GNOME version to GTK3/PyGI. A user named Micke Prag is porting it to QML which means it will be available on MeeGo one of these days. I wanted to apply for the developer’s N950 program (to port SF) but I was on honey-moon when it was announced and I ended up forgetting about it…

Revenge of the clones

When I first developed SF in 2009, I did it to scratch an itch and I couldn’t find such an app when I googled for it, I even wondered if anyone apart from me would be interested in such an app. Short after, my friend and colleague from the University, Paulo Cabido told me how much he liked the idea and created DroidSeries, a SF’s clone for Android. After a while I also found SeriesWatcher, a clone in Qt that also ran on the Linux desktop, Windows and Mac OSX.
What surprised me was that last week I was browsing the Android Market (out of curiosity, I don’t own an Android phone) and found out that there are:
* Series Droid (notice the name? If my friend Paulo was M$ or Apple, he would sue their asses )
* TV Show Favs
* TV Start
* Episode Calendar (this seems to be the only Open Source one in the list)

Although only DroidSeries and SeriesWatcher say they are based in SF, I like to think the others do as well (maybe indirectly like being based on another clone ). Or maybe those were developed before SF and I didn’t notice… What I’m trying to say is that not only from mainstream platforms come nice end user apps. In the Maemo world, even though we have problems of other nature, we also have good ideas and good applications for end user.

Get SeriesFinale 0.6.8 soon from your N900′s updates or here.

Last week, after a delayed flight that shortened my trip in one day I finally arrived in the fascinating city of Berlin to attend LinuxTag.
This was my first time in this event and I really liked it. The event’s program was very interesting, too bad my German isn’t still good enough to be able to fully understand the presentations in German (which was about half of the program or more). There were also booths with interesting stuff going on, from companies to the most well known Open Source projects and also some alternative things like a lockpicking hands-on.

It was a great place to talk to people and get more aware of what’s going on in Germany, and a lot seems to be going on.

On Wednesday afternoon, I presented OCRFeeder and couldn’t be happier after all the feedback I got in the questions session and afterwards. Probably a couple of bugs that were filed after the event have to do with that

You can find the slides here.

(me, presenting OCRFeeder at LinuxTag 2011)

OCRFeeder’s new release

Yesterday I finally finished the latest OCRFeeder version, 0.7.5.

Here are the highlights:

* It is possible to edit the content boxes’ bounds by dragging their edges or corners;
* When selecting a content box using the menu or keyboard shortcuts it will automatically focus their text area. This was suggested by Joanmarie for improving the usability of visually impaired users.
* Added the missing dependency of the “sane” module
* Changed some mnemonics in the menu to avoid clashes (thanks to Łukasz Jernaś)
* Prevent problems when adding image paths that do not exist (from the command line)
* Reset the OCR engine when it doesn’t exist. This bug happened when the settings pointed to an engine that no longer exists (if you passed the conf folder to another machine without the engines, for example) and would prevent the automatic recognition from doing the OCR step.

For other news, like the always amazing translation work, check out the NEWS file.

Source tarball
Git
Bugzilla