Archive for the 'Jokosher' Category

Speaking At LugRadio Live 2007

Monday, June 11th, 2007

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.

My Year In Review

Saturday, December 23rd, 2006

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.

Jokosher 0.2 Released

Monday, November 20th, 2006

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.

Beautiful i18n Graphics Part 2

Friday, October 20th, 2006

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!

Beautiful i18n Graphics

Friday, October 13th, 2006

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.

Outsourcing Stability or Open Sourcing Stability?

Thursday, August 3rd, 2006

Last weekend it was very hot. So me and my family went up to my uncle’s house on the lake. But of course when we get there, my uncle requests my help to fix his Internet Explorer. Right after you launch IE, it closes itself. But he has no idea what would be causing the crash.

I have seen this before, so I immediately uninstall and extra ‘toolbars’ that the crazy internet has installed in his browser. Turns out that after uninstalling the Yahoo! Toolbar, IE works fine (well actually not fine — but that’s how its supposed to work).

Of course the next thing I did was install Firefox. Then if that ever happened again, he wouldn’t be stuck without internet. But this raises a question in my mind. It wasn’t some dodgy spyware or anything that broke his browser — it was Yahoo!. I think Yahoo! is a respectable company, and they have a reputation to maintain. So why would their plugin for IE be so unstable?

This is relevant to me because we are in the process of creating the Jokosher 0.2 extension API. I would really like it if someone as popular as Yahoo! made an extension for Jokosher. But I would not like it if a user installs an extension and gets rewarded with Jokosher crashing immediately after startup.

We could just use DBUS and keep every extension on a long leash and a separate process, but that would hinder possible integration with the core code. We could also use a lot of exception handling, but that would only work if there was an exception, and not if there was a freeze.

The other possibility is that Yahoo! didn’t have the source code for IE so bugs of that kind could not be found during their testing. Maybe I shouldn’t worry about it at all and just trust the extension writers. Or better yet would be the creation of extensions.jokosher.org where we peer review everything. Of course the only problem with that is that I don’t feel like reviewing every single extension. Any suggestions?

Jokosher Update: Since the launch or 0.1, I have been mostly working on getting translations working. We have all the strings in the POT file with the exception of instrument name (but I’m working on that). If anyone feels like translating please go to: http://launchpad.net/products/jokosher/trunk/+translations
We already have four languages more than 50%!