Laszlo Pandy

The GNOME Foundation has generously sporsored me to attend the GNOME Python2011 Hackfest in Prague. I will be working on porting Jokosher to the new PyGObject bindings which use GObject introspection, and Gtk 3.0. I will identify problems I have while porting, get a chance to talk to the developers and hopefully fix all the issues for other application developers before the new PyGObject is released.

I’ve already started porting Jokosher, but there is still a lot do to. I’m working on the easy stuff so far, and probably won’t get to the difficult bits until next week in Prague. But I’ve already found, and created patches for two simple bugs: one to identify the file that a dynamic module is loaded from, and another to list all the available attributes of the module. Both of these make it easier for me to use PyGObject in an interactive terminal; something I am doing a lot of while I am porting Jokosher and need to check the new method names.

I would like to thank the GNOME Foundation and the sponsors of this hackfest (especially Collabora) for funding the hackfest, and my attendance. I get a great opportunity to visit Prague and meet many really cool Python hackers. Thanks!

Jono Bacon asked me to hold a session on GStreamer and a session on Cairo for the Ubuntu Opportunistic Developer Week.

My GStreamer session went well. The IRC log is available online. I went through my slides which explained how to do a few simple things in Python. I used playbin2 to implement audio/video playback with pausing, seeking and position queries to update the slider. I was impressed how simple the code is; only 120 lines of Python.

I was less impressed with my Cairo session. Unlike with GStreamer, I couldn’t think up a clear use case that I could explain the solution to in under one hour. Instead I went through the very simple cairo API and showed how to use it with GTK or with PDF, PNG and SVG file formats. The IRC log and the code as online for this session as well. I did not make any slides.

Jokosher

This week Michael and I also released a new version of Jokosher. It is available on the download page on Launchpad even though the Jokosher website has not been updated yet.

Little has changed in this release so when we get around to changing the website there won’t be an announcement or anything. The reason for making this release was to get a bug fix out for a blocker which prevented Jokosher from running at all with newer versions of GTK. We wanted to get this done soon so it could be in the Ubuntu Lucid release, and the packaged version wouldn’t be broken. We also threw in a few other bug fixes while we were at it.

Saving data in an XML format has been all the rage for many years now and is the basis for both of the highly debated OOXML and ODF document formats. Part of the reason for its popularity is that many claim it is much easier to understand than the binary file formats of the previous generation. They might even say it is self documenting.

But as Håkon Wium Lie, the CTO of Opera once said:

…I’m no fan of either specification. Both are basically memory dumps with angle brackets around them.

He was talking specifically about the document formats competing for standarization at the time. More generally, he was talking about the whole idea of XML file formats. I remember thinking about Jokosher’s own file format after hearing this quote. It is an XML based format that I largely designed myself.

I will admit that our format is in a lot of ways a memory dump with angle brackes. The main nodes <Project>,<Instrument> and <Event> have the same name and structure as the classes that implement them. Each of these nodes also has a subnode called <Parameters> which is simply a list of the variable name, type and value of all the class variables. This only works well for simple data types; for list and dictionaries we have more complex structures.

In previous versions of Jokosher, I needed a easy way to store the very large list of volume levels used to draw the waveform. I figured that putting each number in its own XML node would take a lot longer to parse and consume much more memory than necessary so I created one simple node that looked like this:

<Levels value="0.911560058594,0.913299560547"/>


Imagine the above except with three thousand floating point levels, as is required for a typical five minute song. At this point it starts to get messy and stops looking like proper XML. It is also harder to decipher, and much more like a memory dump. Luckily the current version of Jokosher does not use this anymore. I stores the level data in a separate file that is just a raw dump of the bytes from the array.

Even though I have just shown Jokosher’s file format to be essentially a memory dump with angle brackets, I don’t feel bad about it. It makes our job as programmers easier, and the whole program is still simple enough that you can figure out most parts of the file format without documentation.

Today I had the chance to look at the file format used by Apple’s GarageBand, a program with a very similar purpose to Jokosher. It was interesting to find that like Jokosher, GarageBand has a folder for the project which contains the project file as well as a separate folder for all the audio files. Also just like Jokosher the project file is XML based.

After a few <dict> nodes obviously representing a dictionary data structure, there is a <data> node containing (wait for it…) 2584 lines of base-64 encoded data, and the entire XML file is only 2794 lines! Talk about a memoy dump with angle brackets. And you though your file format was difficult to interoperate with! If you really want to peer at the impurity, you can download the entire file.

Many Jokosher users have been inquiring about support for JACK for some time. Since 0.9 we have had support for using a custom playback pipeline, but you could only use ALSA for recording. After removing the DBus code which we used to retrieve device information from ALSA we can now use whatever recording backend is supported by Gstreamer.

Since we removed our ALSA specific code, we now use the GstPropertyProbe interface on the “device” property to retrieve the list of devices. Currently this only works with ALSA, but if you are using Gstreamer from CVS the patches of mine that were recently committed make it work with PulseAudio as well. JACK does not support the “device” property at all, since the JACK control panel is used to select devices.

As an added bonus, removing the ALSA specific code will make it substantially easier to make Jokosher work on Windows. None of our developers are doing a Windows port,  but if you are interested you are certainly welcome to try it out and see if it works.

This code is not yet merged into the main branch, but you can get it from the custom-audio-src branch in Launchpad and give JACK a try.

For the first year of my involvement with the Jokosher project, one of the questions which came up often was: “Is Jokosher a Gnome application?”. This needed to be decided if we were going to include hard dependencies for Gnome libraries. On the other hand, we heard from a few users who didn’t run Gnome, and liked the fact that Jokosher didn’t drag in loads of dependencies. Of course the disadvantage here is less integration with the desktop. As far as I know, all the developers for the project run Gnome, so integration would be nice.

Eventually we decided that we are a Gnome application, but so far we have yet to add any hard dependencies. I have wanted to integrate Gconf for a while now, but I never find the time. Even though we don’t have the Gconf or GnomeVFS (now GIO) dependencies, we always felt as if we were part of the Gnome community. I mean our mailing list is at gnome.org.

I am a little late on this one, but everyone is talking about the awesomeness that is the Linux Hater’s blog.  Last month the Linux Hater wrote a very nice article about how to write a Gnome application. This was a follow up to the very popular article: How to write a KDE application. Since I have never written a KDE application, I have no comment there. But I would like to see if Jokosher followed all the steps, so here’s my analysis:

Find some reasonable app from another platform (Windows, Mac, KDE, whatever, but preferably, Mac). Bonus points if there are already 3 other gtk-based alternatives who don’t want to integrate with Gnome.

We don’t really like to compare Jokosher to Apple’s Garage Band, but it does make it easier to explain the concept to people so I guess we are guilty of that. But I am glad to say the reason we started Jokosher is because there is no GTK+ multi-track audio editor (single track audio editors are totally different and don’t count).

You MUST have a g somewhere in the gname. Extra credit if you can make it a “gn”. If you can use “gnu” or “gno” or “gna” you’re are gnawesome, and your app is already worth using. Make sure the name of your app bears no relevance to what it actually does. Also, NEVER document if the g is pronounced with the hard-g sound.

People have told us that Jokosher is a ridiculously stupid sounding name, and yes it does not have any relevance to what the program does, but still there is no g.

Use at least two object frameworks. Three is even better. I mean the “O” in Gnome stands for object, after all. Take your pick from Corba/Orbit/Bonobo/D-bus. Make sure at least one of them works over the network, but make sure your app never actually uses it over the network.

Nope sorry. I really want to give Jokosher a DBus API, but I haven’t got around to it.

Remind yourself that OO in C is not so bad. assert(gtk_no_really_its_not_so_bad). Also, remind yourself that GTK+ is way better than Qt because it has no commercial company writing code for it. So, you know, it’s more free, or something, and it’s got a + in the name.

Phew, we escaped this one. We don’t have to use C because the entire program is written in Python. And we don’t use Qt because at least at the time PyQt and PyKDE were poorly maintained and lacked any community or documentation.

Generate wrappers for every conceivable language, but make sure none of them work exactly how you want. Inisist that your distros package each wrapper in a separate package.

Since we decided to write Jokosher in Python, we weren’t intending to write bindings for any other languages – especially C. This is more of a library thing anyway, not a desktop application thing.

Explain to at least three other programmers how glib doesn’t really have much to do with gnome. Because they care.

What is glib? All the types and data structures I use are the Python ones.

Don’t forget a Tango Icon!

This one is dead on. We had Tango icons before we had audio support, and we’re an audio application! But there’s no way you can argue this is a bad thing. Tango is great.

Make sure your app builds on windows, but looks like ASS.

We’ve been meaning to try this, but we have some ALSA specific code right now and no one wants to take on the challenge of compiling Gstreamer on Windows. I disagree with the ass part. If there’s one thing Jokosher does well it is look good!

Enumerate all the features you want your app to have.

Cut 90% of them. Because they’re hard to do. But tell everyone that they don’t actually need that feature.

Implement 2% of them. Hide the other 8% in gconf. Hide them well.

There are a lot of features we would like to do, but are very difficult both from an implementation perspective and a usability perspective. But given enough time we will get to them as long as we can find away to do it without crowding the interface. Despite what the Linux Hater says, it is sometimes better to leave a feature out than wreck the interface with it. Also I have been meaning to hide features in Gconf, but like I said I never got around to it.

Your interface must not have more than 4 buttons.

Each instrument in Jokosher has at least four button on it. Plus three more that appear in the selection context. Despite all the yelling there is a balance there between too many and too few buttons.

Make sure it depends on at least four other libraries with g’s in their name. That raises your apps’ gnomyness

Gstreamer, GObject (doesn’t really count cause its part of GTK+), Glade. That’s only two. Three if you count Gnonlin.

Don’t use Mono, because you are spreading your STD’s to everyone. No, wait, use Mono, because it will make you way insanely more productive. Wait, no, don’t use Mono, because if you do, some freetard distro that nobody uses won’t distribute your app.

No Mono, got it.

Depend on a module that is “heading toward planned deprecation” so that it will now be “at the end of the Obama presidency we will almost have consensus of heading toward a planned deprecation over 20 years.”

I don’t think we’ve ever done this. We started using Tango icons and Cairo graphics pretty early on so I think we are far enough past deprecation.

Ressure yourself that even if your app sucks, at least it follows the HIG.

Wow. What a perfect one to end with. I don’t think you could sum up Jokosher in a more controversial way than that. It’s true Jokosher sucks at what it is supposed to be good at, namely recording and mixing. Yes most of these are problems with Gstreamer that we haven’t managed to fix yet. And yes it sometimes doesn’t like your hardware and sends crazy opaque error messages. But many people have told us how much they like the interface, and we love giving it a lot of attention and polishing it up. We follow the HIG almost religiously. 100% guilty here. Damn.

Four or five out of fourteen depending on how you count it. Either way that’s a fail. So according to the Linux Hater, Jokosher is not a Gnome application. Let’s assume that’s a good thing.

Despite the fact that I live approximately six thousand kilometers away from the venue, I will once again be making the trek to Wolverhampton, UK for LugRadio Live. I was lucky enough to be able to attend LugRadio Live last year and host the Jokosher BOF session, but this year I have been invited to give a lightning talk about Jokosher.

What the organizers refer to as a “lightning talk” is actually a 25 minute presentation in a decent sized room. It isn’t as big as being on a real stage but its big enough for me. This will be the first time I’ve done public speaking outside of my high school. Let alone that it is in a foreign country and in the presence of people who are much smarter than myself.

My talk will be entitled “Inside Jokosher” which doesn’t really give you an idea of what it is about, because to be honest when I made up the title I didn’t know what it was going to be about either. Now that I have the details of my presentation ready to go, an appropriate subtitle would be “A power user’s guide to the most open and flexible audio editor available.” Now I an making the assumption that Jokosher is more open than much of the competition and that using Python and Gstreamer makes it much more flexible. But to know for sure if I am right you’ll have to come to my talk and find out for yourself.

For those of you who can’t justify flying across the entire ocean for just one weekend, or can’t make it for some other reason, I believe there will be a video recording of most of the presentations, and I will probably end up turning my talk into an official power user’s guide for Jokosher.

Of course LugRadio Live will be on the 7th and 8th of July in Wolverhampton, UK. You can find out all about it at the official site.

At the beginning of this year I was sitting in my dorm room listening to LugRadio, thinking about how awesome the open source community was and how much I wished to be a part of it. Up until that time my entire open source contribution amounted to a few patches and bug fixes with Amarok. I imagined what it would be like to help out the community, get kudos from everyone online, and piss my pants laughing with the dudes from LugRadio.

It’s not that I couldn’t contribute. I had two years of Java experience from high school, but I had no idea how to do C++ so I struggled when trying to make a difference hacking on Amarok. I also went the Ubuntu Breezy Summit in Montreal and tried to join the Ubuntu Documentation Team, but I didn’t have the initiative to start writing something on my own. It seemed much too difficult to start contributing even though I had novice programming skills.

In March 2006, Jono mentioned on LugRadio that someone had started the code for his JonoEdit idea. He also mentioned that they desperately needed contributors to write code in Python, and that everyone should come on board now while the code was small and easy to learn. I already knew Python and it was my favourite language, so I took his advice.

I only mention this now because back then I never would have thought that in less than a year I could go from writing useless Python scripts on a Saturday morning, to being hated and envied by the massively hilarious dude I hear every second Monday morning. In my book, that’s quite an accomplishment.

I guess my point is that no matter how hard you have tried to contribute and integrate yourself into a new community, and no matter how many times you feel like you have been rejected, all you have to do is keep moving until you find your passion and it will be smooth sailing after that. It turns out my passion is programming in Python, and now I’m responsible for a large part of Jokosher.

After the gigantic Jokosher pimpfest that was the Ubuntu Developer’s Summit, Jokosher v0.2 has been released, and #jokosher on irc.freenode.net is swarming with Ubuntu folk trying to jump on the bandwagon and compile gstreamer CVS as fast as possible. Thankfully for the Ubuntu users, this is rather simple because of Aq’s wonderful script which will download, and compile Jokosher and Gstreamer CVS all in one step. You can download Aq’s script, or the source tarball from the download page.

There are lots of new features and improvements over v0.1, the most important of which is that it doesn’t suck anymore, and you can actually accomplish useful things. Also we have support for third party extensions a la Firefox, so if anyone wants to write one (there are examples included with the release), or help improve our cool API, give us a shout.

Finally, I have managed to get all the Jokosher dependencies for w32 with the exception of one — Gstreamer — which also happens to be the most important dependency. I am definitely not looking forward to intalling all the Gstreamer build dependencies on Windows. If Gstreamer people knows a better way, or if this is at all feasible, please let me know.

Is it not the case that one person could build Gstreamer for w32 and then just copy the folder to any other windows computer? I mean it’s all binary compatible right? If I do ever get it built, then we could just tar-up the entire directory with Gstreamer and Jokosher and make that the w32 version. It would be about 100 times the size of the Linux tarball, but it would be worth it.

Last week I discussed how nice it would be to have graphics in your application use gettext to translate all the strings in the image, and render a localized version on screen. I showed how this would help usability, and improve the overall look and feel of the desktop. I also discussed several ways to accomplish this, many of which would require cooperation from various libraries.

I decided that if I wanted to get it done, I a) had to do it myself, and b) would have to do it programmatically on a case by case basis to ensure that things like text wrap or overflow are handled uniquely for each image. Here is the original image that Jono made using the Gimp:

Now here is a rendering of my GTK widget which uses Cairo to try and accomplish the same thing:

As you can see the images are identical with the exception of the font. Currently I am using cairo.show_text() in Python. However in the cairo reference manual it says:

NOTE: The cairo_show_text() function call is part of what the cairo designers call the “toy” text API. It is convenient for short demos and simple programs, but it is not expected to be adequate for the most serious of text-using applications. See cairo_show_glyphs() for the “real” text display API in cairo.

However Cairo does not provide a way to get font glyphs, and documentation says that you must get the glyph yourself. Being a person who doesn’t know anything about how glyphs are stored, or how to get them in C (let alone Python), I’m kinda stuck.

If anyone has an example of how to make text beautiful with cairo_show_glyphs(), or any idea how to do glyphs in Python, please let me know!

A while back I submitted a bug to Tango, because the word processor icons for bold, italic and underline were a bold, italic and underline ‘A’ respectively:

I wrote in the bug that, like almost everyother word processing application I had ever used, the icons should be a bold ‘B’, an italic ‘I’ and an underlined ‘U’. The response to my bug was that to be fair to every language that the application supports, and to avoid making a new icon set for every language, they decided to use ‘A’ for all three icons. In reality however, I would imaging that a Japanese or Russian user might be confused by the latin character in the icon. So in every case, this is suboptimal.

One of our primary goals for Jokosher v0.2 is internationalization support. Like everyone else, we now use gettext. Another one of our goals is LADSPA effects support. In fact, Jono was so excited about implementing audio effects, he made this beatiful banner which sits at the top of the instrument effects dialog:

It goes without saying that images like this one make Jokosher a much prettier application, and benefits the overall user experience. We could also use different colours for the images at the top of different dialogs so people could easily remember which part of the application they are in. This would be more useable than the current state of all the buttons and dialogs looking identical. In fact this is one of the demos that was given when Cairo came out; many buttons on the screen each with their own random variation generated at runtime. Now computers are fast enought that we can use SVG and Cairo to do fancy vector graphics on the fly. Jokosher uses both, and we really like the results.

As soon I saw the intrument effects image Jono did, I told him two things: “That looks awesome!” and “It’s not going to work, and you’ll have to get rid of it.” The second of course refers to the fact that i18n is now a priority for Jokosher, and that image has English text in it. Now we have a problem.

Luckily this problem can be easily solved by using gettext and rendering the image at runtime. In other words, librsvg + gettext = awesomeness. One very hackish way I thought of to do this was loading the SVG as text, doing a quick find of all fields, replacing them using gettext, and then feeding the altered XML into librsvg. I’m not sure if this would work. Nor am I sure if the SVG specification has a translatable=”yes” tag like in glade XML. If not, there could at least be a switch somewhere which would make librsvg treat every string as translatable and call gettext, in exactly the same way glade does!

This would unleash awesome new possibilities to make GTK apps the most beautiful ones known to man. And it would help usability too, by allowing the bold, italic and underline Tango icons to use the user’s native alphabet and character set. If anyone has any other ideas for how to accomplish this, please let me know. I really don’t want to have to take the instrument effects image out of Jokosher 0.2.