A Python clone of the grilo-test-ui is provided, and should give you an idea of what can be done with these new bindings: basically enjoy all the power in Grilo without needing to touch C code, and without us having to maintain manually created bindings.

If you’re a JavaScript user, then you need to watch bug #616961. As JavaScript doesn’t support GParamSpecs yet (#626047), you’ll need this patch which replaces GParamSpec annotations with uints. And now, time for unit testing with PyGObject!

Using Grilo bindings from Python console

grilo-test-ui using GObject Introspection bindings

Missing GParamSpec when accessing from JavaScript

To watch an entire product, lookup the product in this page. This will show the default assignee (often productname-maint@gnome.bugs). Then add it your your watched users list.

An easy one, but as it took me a while to find it, I put it here as a reference.

Todas las charlas quedaron grabadas en vídeo, y la organización se encargó también de recoger las presentaciones, así que no creo que se tarde mucho en publicarlas en la página del evento: son todas muy recomendables. Y, para ir haciendo boca, aquí están las mías: en ellas se habla de Jamp, la aplicación desarrollada en el módulo de Desktop & Mobile del máster. ¡Que las disfrutéis!

Maybe it’s still a bit longer than it should, but hey!

So, if you want to know those issues we faced with JaMp (GObject signals, D-Bus -from both C and Python sides-, and some notes about the Maemo port) come visit us to the Computer Science Faculty at A Coruña on 23rd July -next Friday- at 13:00. Grab the program here.

• My manager (I don’t like how “boss” sounds) retired last week. Although he visited us a couple of days more to spend some time with us, things will be, at least, different. We’ll surely miss him.
• I started working with Grilo at Igalia, as the practicum work for the Free Software Master. I’ve been assigned a challenging task: improve the bindings infrastructure. Currently I’m getting familiar with the project, reading the doc and playing with the examples: it looks really interesting!
• Yesterday I received permissions to upload to extras-devel, so… maevies & butaca-server are available now! Of course, all said warnings about extras-devel still apply. In my case, it’s about memory consumption: the backend doesn’t free the objects exposed via DBus, so you have to kill it to get that done. It’s a small footprint and all that, but it’s not nice and of course not the way I want it: having it uploaded to extras will get me motivated to fix it (Sure, there will be other issues as well, and I’ll set up the bugtracker as soon as possible)
• I’ve started with the slides for the JaMp talk at GUADEC-ES. There’s still time left, but with these things, you never know…

More info on that soon, but you can start by checking the program. Or even better: why don’t you register and visit us?

At that moment, I was going to the cinema maybe twice a month, and as some of my friends have the (sometimes annoying) habit of waiting after the credits to see if the movie has extra scenes or something, I thought it would be nice if I had an app in my phone which could tell me if it was worth waiting. A nice brainstorm started, and we added showtimes and other movie info to the app, so Maevies -from movies + maemo- was born. After that, it was “just” a matter of researching which web services could provide that info.

We got the backend “working” rather soon. We started using librest and synchronous calls, so the user would be blocked until we got a response from the web services. We wanted to have a basic backend functionality, and quickly focus on the UI but… we stopped there. We met a couple of times to get started with the UI, but didn’t get too far.

About a month ago I announced that we were starting the development module in the master and that, after having enjoyed an introduction to python, I was quite convinced to port Maevies to Python. Then, I commented in the same post that I wouldn’t port it, but mimic the architecture we’re using for the master app: C with GObject for the model, and Python at the view, connected using DBus. Soon I had all the old maevies backend adapted to use GObject, all the librest references removed and replaced with libsoup’s, and a basic prototype with PyMaemo, with a fake behaviour like the one I would expect from the actual app.

Today, I can announce a “functional” pre-alpha version of Maevies. I’ve created a page for it at this blog, and linked it from the maemo garage’s one, have taken some screenshots, and pushed the last commits (yeah, I also migrated from subversion to git, now that I’m feeling really comfortable with it).

So what’s going on with maevies?

• About the backend: A movie can be searched in themoviedb.org -getting its basic info- and whatsafterthecredits.com -getting the information about extra scenes. There is also a module which parses Google Movies html, not using GObject yet, but some changes in their API seem to have broken its support.
• About the user interface: The user can query for a movie using themoviedb service, retrieve a list of results, and display the basic info for the selected movie. (The DBus service must be brought up manually, as I didn’t create the .service file to allow DBus doing it). Besides the screenshots below which should give the general idea, there’s this screencast. It has, however, a lot of flickering: it’s been recorded with the app running under Xephyr, using Istanbul. If you know a better way to record a screencast, please drop me a comment

And what are the next steps?

• Not all the TMDb retrieved data is exported via DBus, nor displayed later on the UI, so that would be a point.
• It would be nice to display the movie images, also.
• Bringing the whatsafterthecredits info to the UI would finally add the initially desired functionallity

Welcome Window

Search Dialog

Search Results

Movie Info

There’s a design pattern, the Observer pattern, used to allow “subscribers” to track or follow state changes happening on an object, the “subject”. In C#, this is implemented via Events, in Java you have the Listeners, and in C, with GObject, you have signals. Going to the GObject implementation details:

enum {
        END_OF_STREAM,
        LAST_SIGNAL
};

static guint
jmp_mplayer_signals[LAST_SIGNAL] = { 0 };

The enum “tags” our signals. In this case, we just have one: END_OF_STREAM. LAST_SIGNAL is a convention: as it is in the last place, it will be always “our last real signal” + 1. And that’s used in the next line, when we declare an array storing those signals: it will have “LAST_SIGNAL” size. It doesn’t store the signal itself, but its identifier, but we’ll see that later.

jmp_mplayer_signals[END_OF_STREAM] =
                g_signal_newv ("end-of-stream",
                                G_TYPE_FROM_CLASS (klass),
                                G_SIGNAL_RUN_LAST | G_SIGNAL_NO_RECURSE | G_SIGNAL_NO_HOOKS,
                                NULL,
                                NULL,
                                NULL,
                                g_cclosure_marshal_VOID__VOID,
                                G_TYPE_NONE,
                                0,
                                NULL);

That is how the signal is created. It calls the gobject function g_signal_newv which creates the signal, and stores its identifier in the array position given. But, what means each of the params? Well, to be honest, I don’t know too much:

The first one is easy: “end-of-stream” is the signal name. The documentation sets some limitations to the characters it can contain, but that’s all.
The second one is “the type this signal pertains to”. The macro G_TYPE_FROM_CLASS gets the type from the class structure (klass).
The third one is composed by signal flags. They “specify detail of when the default handler is to be invoked”.
I don’t know about the next three params: documentation says class_closure, accumulator, and accu_data. As soon as I learn what they do, I’ll update this. Setting them to NULL worked fine for my needs.
The fourth one, called c_marshaller, sets the interface for the callbacks listening for our signals. So, in our example, g_cclosure_marshal_VOID__VOID means that we won’t require our callback functions to receive arguments. You can find more closures here.
G_TYPE_NONE defines the return type for our callback, so our callback (closure) signature would have this form:

void end_of_stream_callback (JmpMPlayer *self, gpointer user_data);

Our last two params are the length of param types, and an array of param types.

So, what is left? Well, our “subject” still has to notify (“emit”, in GObject) his subscribers. And those subscribers need to actually “subscribe” to the signal. Here we go:

switch (GST_MESSAGE_TYPE (message)) {
        case GST_MESSAGE_EOS:
                g_signal_emit (self, jmp_mplayer_signals[END_OF_STREAM], 0);
                break;

g_signal_emit receives an instance the signal is being emitted on, the signal id (which we had previously stored in that array), and a detail. Quoting the documentation,

detail identifies the specific detail of the signal to invoke. A detail is a kind of magic token/argument which is passed around during signal emission and which is used by closures connected to the signal to filter out unwanted signal emissions. In most cases, you can safely set this value to zero. See the section called “The detail argument” for more details about this parameter.

And this closes the circle: subscribing to the signal.

g_signal_connect (jmplayer, "end-of-stream",
                          G_CALLBACK (end_of_stream_callback), loop);

g_signal_connect connects a given callback (G_CALLBACK (end_of_stream_callback), whose signature we saw before), with a signal in an instance (jmplayer), passing arguments (loop)

To write this entry, I’ve relied on two documents: API Reference’s Signals and The GObject messaging system’s Signals, and the (yet little) knowledge I acquired during this stage of Jamp implementation (which, itself, required Víctor‘s help and said documentation). Full code for this example is available at Gitorius, for both the “subject” and the “subscriber”.

But that was on Friday. On Saturday, we started with the first workshop. During the module, we are going to develop a Gnome desktop application, which will be later ported / adapted to Maemo: a Jamendo client called Jamp. The application has ben designed / is being designed with that port in mind, so hopefully we won’t need too many changes to achieve it. We’ve been distributed between three teams: UI with PyGTK, web API connection with libsoup, and multimedia playback, with gstreamer. Wikipedia says

Jamendo is a music platform and community.

All music on Jamendo is free to download and licensed through one of several Creative Commons licenses or the Free Art License, making it legal to copy and share, as well as to modify and make commercial use of for some, depending on the license. Jamendo allows streaming of all of its thousands of albums in either Ogg Vorbis or MP3 format, and downloads through the BitTorrent and eDonkey networks.

So, while we learn, we’ll be contributing to a Good Thing™ . I’m very motivated about using git, doing a team development, submitting patches, and enjoying such a collaborative environment.

I’ll try to keep you updated

I don’t know exactly when it was, but I once came to maemo IRC channel to ask a specific (maybe too specific) question about ESbox. I was surprised that nobody was using it: people there were using nano, vi, Emacs… I asked them about all the features a “full IDE” offers: what about code refactoring? what about autocompletion? debugging? While some said that you can get emacs to auto-complete from a given dictionary, the other questions remained unanswered. In fact, I almost felt like we weren’t talking the same language.

Our discussion wasn’t constructive at all: I don’t know if it was the language barrier, if it was me who said something inappropriate in the beginning, or if I met people too “Taliban”. The thing is that I had to listen things like “real programmers know the name of the functions / methods they need: autocompletion is for dumbs”. And no, it wasn’t a joke like “real programmers develop their own device drivers”. So I gave up and left the channel: I assumed that programmers would choose their IDEs according to the kind of development they were doing, so “hobbyists” would use nano, would copy & paste and wouldn’t care too much about extras, and “professionals”  would use others, or at least would know and use the extras I wanted. And time went by.

As I was telling you in the last post, this Friday we’ve got our first session in the Desktop & Mobile development module of the master. After its presentation, we had a brainstorming to choose which app we will be developing during the workshops, and then… we started talking about IDEs. More specifically, Emacs.

That gave me the opportunity to confirm that there really was a difference between professional developers and non-professional, and that my worries were really shared by others. It was a really interesting chat, where we were explained the environment, from the basics (navigation a buffer, open, close, kill and yank…) to more complex things: debugger integration, syntax highlighting modules, autocompletion, macros…

After the session, I now can understand other people not using Eclipse or Netbeans, while still being productive. I’m not going to use Emacs, not yet, as it looked like some of the features that “just work” in Eclipse require some fiddling in Emacs; but at least I know that someone using Emacs and mastering it will be as efficient as an Eclipse user -or even more.

Still, when I think about the things I like to have working in Eclipse, the following comes:

• Version control: I’d like to be able to check history, undo changes across revisions, commit changes, check “who did what” (blame)
• Debugging: Set breakpoints, set conditional breakpoints, step by step debugging, variable inspection
• Syntax highlighting, code folding, autocompletion (preferable if it can include code I’ve done, not only know APIs), code refactoring (variable names, methods, etc), comment & uncomment.
• Compilation management: Make integration (or other options like ant or maven for Java). Build automatically, “live” syntax error detection.
• Bug tracking system integration
• GUI editor

I know that I can do all of the above using Eclipse, and since this Friday I know that some of them are also possible with Emacs, so now I’d like to have some feedback:

What do you expect in an IDE? Is your list similar to mine? What is your IDE of choice? Which special options of your IDE you use the most? Which options are you most proud of?