At the 2011 Desktop Summit in Berlin

Posted in Uncategorized on August 7th, 2011 by laszlo – Comments Off on At the 2011 Desktop Summit in Berlin

I am here in Berlin at the Desktop Summit. Thanks to the GNOME Foundation for sponsoring my travel and accommodation.

GNOME Foundation Sponsorship Logo

Actually the reason I wanted to come is to attend the GObject introspection hackfest starting on Tuesday. But the GNOME Foundation decided if we were coming to Berlin anyway, the hackfest participants should come a few days earlier and attend the talk on the weekend.

It’s great to be in Berlin for a few more days, and during the talks I’ve already started hacking on PyGObject in preparation for next week.

I also love that my employer, PreziPrezi Logo, has given me the whole week to attend the summit and hackfest. Visiting conferences is one of the perks of working at Prezi. Even though the Desktop Summit has little direct connection to my work there, they are paying me to go anyway.

Prezi is almost certainly the best place to work at in all of Hungary, and probably most of eastern Europe too. If you’re interested in working in Budapest, we are hiring.

Glipper 2.1 release

Posted in Uncategorized on April 22nd, 2011 by laszlo – 1 Comment

One of my favourite small utilities is Glipper. It is a little applet that records your clipboard history and let’s you reuse multiple things you have copied.

There are plenty of clipboard managers for Gnome, but this is the one I started using. And I like it enough that I don’t care to switch. But as a Gnome panel applet, Glipper does not work with Ubuntu’s Unity or Gnome Shell. Since it is written in Python, I figured it wouldn’t be too difficult to fix this.

Glipper 1.0 is a Gnome panel applet and has not been updated since 2007. After asking on the mailing list, I was able to get permission to take over maintenance. The sourceforge page was closed down, and I put everything on Launchpad. I moved the code to Bazaar and started cleaning up the code.

After removing the custom C code to bind global key presses (using python-keybinder instead), I was able to remove autotools and replace it with distutils. I then removed the deprecated Gnome libraries and Gnome applet code, and used Ubuntu’s appindicator library instead. This was really straight forward because appindicator accepts a Gtk.Menu, which Glipper was already using for the applet menu.

Glipper 2.1 screenshot

Last week I made a release on Launchpad, and figured out how to build a deb package. It was my first, and using distutils made it really simple. I made a PPA, and yesterday I requested that it be put in Natty.

Interestingly, when I asked for help to get it pushed into Natty, it was Martin Pitt (who I met at the PyGObject hackfest) who approved the feature freeze exception. And it was my old friend Daniel Holbach who did the actual packaging and upload. That dholbach; how is he everywhere all at once?

Unfortunately the new Glipper only works on Ubuntu or distributions with appindicator support (are there any but Ubuntu?). The Gnome Shell developers have not yet provided a way to make little menus in the panel of the shell. When they do I will try to have Glipper support it right away.

So there you go folks. You can find Glipper 2.0 in Natty universe. Maverick users can use the PPA. The source release is also available.

PyGObject Hackfest Report

Posted in Uncategorized on February 3rd, 2011 by laszlo – 3 Comments

GNOME Foundation Sponsorship logoThe week before last I attended the GNOME Python introspection hackfest in Prague. This was the first hackfest I have ever attended, and the first time I have been sponsored to attend an open source event. It was really nice of the GNOME Foundation to reimburse my travel costs, and of Collabora to pay for the conference.

Collabora logoAll of us who attended are really thankful for Collabora paying for the usual bits, as well as our beers for the week and a traditional Czech duck dinner on the Thursday evening. I don’t think the beer expenses came out to too much because beer is really cheap in Prague and we spent most of the time working and not drinking. Nonetheless Collabora was willing to pay for whatever we drank, and the dinner too, which was absolutely delicious.

The hackfest was at BRMLab, a local hardware hacking club, and although hard to find, was a comfortable space with good internet and a great place to get work done. It was really nice meeting so many cool hackers and talk about all sorts of interesting things over dinner every night.

How I spent my time at the hackfest

I asked to attend the hackfest when J5 asked on his blog for application developers to attend. The week before the hackfest I started porting Jokosher and asking about issues on IRC. By the time the hackfest started I had met a couple of the hackers on IRC, and was getting familiar with the how the introspection bindings worked.

The first three days of the hackfest I worked on Jokosher. It was really useful having Tomeu and J5 in the same room. When I came across issues, I could ask them right there. I quickly figured out that Cairo isn’t going to be wrapped, and so static bindings for cairo should be used. In addition, GStreamer support is lacking, but it isn’t so crucial at the moment because they develop their static bindings separately. The GStreamer Python bindings will still be available for the next major release, unlike with PyGTK, where there will be no static Python bindings for Gtk 3.0.

So for those three days I concentrated only on porting Gtk, and making sure it worked with Jokosher. After getting my patches reviewed and committing them all on Wednesday I was looking for something to do for the last two days. I had run into a few problems with drawing callbacks using Gtk 3 and introspection, and I wanted to work on something less specific to Jokosher and more generally useful.

Improving startup time

At dinner someone mentioned that right now startup time with introspection is way slower than with the static bindings, even though in theory it should be quicker, because most classes are only loaded when they are accessed, and not at startup. I said I’d look into it.

On Thursday hooked up Python’s hotshot profiler and figured out where the slowest parts of the code were. It turned out that most of the time during import was spent in only two functions, both of which were responsible for setting up virtual methods. Both were also recursive, which explained why they took so much time.

In the end, I removed most of the recursion in both functions (one of them will still recurse in the case of an interface virtual method), and managed to reduce the import time with Gtk 3 from 2.5 seconds to 0.4 seconds. That is timed on my computer, with a warm startup (everything still in kernel cache). But regarless, the startup time is now slightly faster than the static bindings for either cold or warm starts.

I managed to grab a power socket on my train back to Budapest to Prague on Saturday, and cleaned up my changes a bit. Then when everyone was back on Monday and Tuesday, I got both my patches committed. If J5 also finishes up his invoke rewrite branch soon, the next release of PyGObject introspection should be much faster.

PyGObject 2011 Hackfest

Posted in FOSS, GTK, Jokosher, Python, Travel on January 12th, 2011 by admin – Comments Off on PyGObject 2011 Hackfest

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!

GNOME Foundation Sponsorship Logo

Opportunistic Developer Week

Posted in FOSS, Gstreamer, Jokosher, Python on March 3rd, 2010 by admin – Comments Off on Opportunistic Developer Week

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.


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.

Curious Linguistics

Posted in Uncategorized on September 9th, 2009 by admin – 1 Comment

A list of English phrases which have a literal opposite that means the same thing in common usage:

I’m down for some ice cream.
I’m up for some ice cream.
I could care less.
I couldn’t care less.
I filled in the form.
I filled out the form.

GeekDeck Issue 3: Brought to you by Pete Savage

Posted in Uncategorized on June 13th, 2009 by admin – Comments Off on GeekDeck Issue 3: Brought to you by Pete Savage

For more than two months now my good friend Pete Savage has been working hard on his new project GeekDeck, and he shows no sign of stopping. Since the beginning he has been bugging me to put together an article for his zine/blog thingy.

I finally got the time to get something I’ve been thinking about for a while down on paper (but not real paper of course), and my article discussing using undo on the desktop to reduce the annoyance of modal dialogs has been published in GeekDeck Issue 3, which was released today. Hope you enjoy it! Here’s a list of all the articles in this issue:

How to mount UDF format DVD+R on Ubuntu Jaunty

Posted in Uncategorized on May 17th, 2009 by admin – Comments Off on How to mount UDF format DVD+R on Ubuntu Jaunty

I was recently given a DVD+R disc created on a Windows XP machine. The volume label is ROXIO, so I presume the application used was Roxio Easy CD Creator. Problem is, when I try to mount this disc using Nautilus or manually on the command line, I get this error:

laszlo@sescento:~$ sudo mount /dev/dvd1 /media/cdrom
mount: block device /dev/sr1 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/sr1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Looking at the system log, shows the following message:

laszlo@sescento:~$ dmesg | tail
[588493.006569] UDF-fs: Filesystem marked read-only because writing to pseudooverwrite partition is not implemented.
[588493.214121] UDF-fs: No fileset found

After googling this problem for a while I found many Hardy users having this problem, and links to solutions which involve patching the filesystem driver and recompiling the kernel module. However I am running Jaunty, which was released just last month. It should have the latest driver necessary to read the new UDF format produced by Roxio.

After finding many Ubuntu Forums threads which were no help, I found a comment on this UDF format bug which apparently has been fixed in Intrepid. The comment mentions to make use of the “session” and “lastblock” mount options.

As the comment suggested, I tried running dvd+rw-mediainfo and getting the lastblock value of 1678800. The following command gave the same error message.

sudo mount /dev/scd1 /media/cdrom1 -t udf -o ro,user,noauto,exec,umask=0,session=0,lastblock=1678800

After playing around with this command for a while I figured out that 1678800 is one of the only values that doesn’t work. Specifying 0 or 1678800 or 1678801 causes the mount to fail. Specifying almost any other number allow the disc to be mounted and read. I can speculate that if the lastblock value seems valid, for example it is close to the end of the track it tries to use it. However with a value that is almost certainly wrong, it tries to search for the proper value. To me it still does not make sense why if the lastblock option is not specified, the disc cannot be mounted.

So for simplicity I will just use the value 1. Here is the command which allowed me to mount the disc successfully:

sudo mount /dev/scd1 /media/cdrom1 -t udf -o ro,user,noauto,exec,umask=0,session=0,lastblock=1

Now its time to listen to the music and watch the movies contained inside.

Ambiguous Adjective Phrase

Posted in Uncategorized on April 30th, 2009 by admin – Comments Off on Ambiguous Adjective Phrase

Yesterday I recieved an email from my university regarding recent news:

Carleton University’s Health Services and the university’s Administration continue to monitor the situation regarding Human Swine Influenza.

I did not realize we had human swine at our univeristy. Did a DNA splicing experiment in the biology department get out of hand? It’s good that health services is concerned for the well being of everyone including hybrid beings.

GarageBand Dumps it to XML

Posted in Jokosher, Non-free Software on December 21st, 2008 by admin – Comments Off on GarageBand Dumps it to XML

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.