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!

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.

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.