Some of you may be familiar with the good old “fix it twice” adage: fix the problem and then ensure it never happens again.
Last year, when I made Pitivi’s automatic backup feature work, I requested someone to write extensive automated tests for it (with Dogtail), so that I could feel confident about this feature never being broken again, even if it underwent massive refactoring or if everything else changed around it.
Turns out that it did break again this year. After the port to GES Assets and GES Project, loading a backup project would not actually populate the media library and timeline! The tests were not strict enough to check those kinds of “details”, so this flew completely under the radar.
I thought I’d fix the whole thing again… however, in addition to not wanting to see it break again later I wanted to be more efficient, so I did things differently this time: test-driven programming. I refactored our automated UI tests, made them much more exhaustive and sadistic, made them fail, and then spent time fixing the code until the tests would pass. And whenever I found another bug in that branch, I wrote tests to fail before I would fix the issue.
Now it works, and I can be confident about it again. I have effectively fixed it thrice.

Why do I care so much about making it bulletproof? Because projects are Pitivi users’ most important data. It is critical to ensure their safety through unsaved changes warnings, disaster-proof automatic backups, backup restoring that actually works, and preventing accidental overwrites: Pitivi tries to gently steer you away from overwriting important stuff (you need to go through the “Save As” process and confirm the overwrite, if you consider the restored version to be the correct one). All that, and much more, is part of my automated tests.

Other recent stuff

Software Center description

I’ve been watching closely as Richard Hughes put forth a proposal for a new specification to describe applications in the GNOME Software Center. Here is what I wrote for Pitivi.
Summary:

A video editor that aims to appeal to hobbyists and professionals alike, with a strong focus on usability, efficiency and quality

Description:

Integrating well with the GNOME desktop environment and other applications, Pitivi sports a beautiful user interface designed to be powerful yet easy to learn.
With a non-modal editing workflow, a framerate-independent and playhead-centric timeline, Pitivi allows you quickly and accurately trim, split and review your scenes. Pitivi’s ripple and roll editing features allow spending more time on storytelling and less time on “pushing clips around”.
Some other features include:

• Accepts any file formats supported by the GStreamer multimedia framework
• Can animate hundreds of special effects and filters with keyframable properties
• Ability to set custom aspect ratios, framerates and rendering presets
• Easy to use crossfades and SMPTE transitions
• Multihead-friendly with detachable user interface components

Hopefully this should capture the essence of what it can do.
On a sidenote, we currently use INTLTOOL_XML_RULE to make this file translatable, and I heard that’s terribly uncool. Please help us by providing a patch to make it work using itstool instead!

New project render dialog, filesize estimates

It feels great when you pick up a patch you wrote “blindfolded” four months ago (back then, it was impossible to test) and see it “just work”: I had this small “Knuth” moment when it not only rebased cleanly, but worked as intended with only one or two Python syntax adjustments. The patch in question is a little feature I wanted to make it easier to figure out if the resolution/quality/bitrate settings I chose are getting me to get the kind of filesize I want: output filesize estimation.

The algorithm I devised is naïve, but does the trick for the vast majority of cases. I cheat a little bit by waiting long enough to have gathered enough data for prediction to be somewhat significative, and by fuzzying the estimates — you’d be surprised how innacuracy can improve perceived accuracy!
While I was doing that, I started playing around to make the rendering dialog prettier and more informative. For starters, the “Rendering movie” header felt wrong for various reasons, and this became quite apparent once you add the “Estimated filesize” text right below it. Rewording the header to say something like “Your movie is now being rendered and encoded” didn’t help much.
That header was basically still duplicating what was in the window title. I pondered what could be put in its place; emptiness would look a bit silly, as the dialog would just be a titlebar, a progressbar and buttons. I then decided to put some informational text for educational purposes: few people actually understand what factors influence the encoding performance (or the speed at which your project renders), yet many people are surprised when it takes a long time, so I thought I’d add a contextual tip:


“What’s that ridiculous amount of empty space below the progressbar”, you say? A bug in GTK, it seems. I spent quite some time changing things all over the place until I discovered that making the window non-resizable “fixes” the issue. My guess is that GTK3’s size calculations are based on the height of the window before its width would be set by the “default width” property in my dialog… and then the height would never shrink. How odd. Anyway, the new text paragraph does prevent the window from being too narrow now, so the dialog doesn’t really need to be resized by users. Here’s how it looks like now:

Certainly more useful than what we started out with, isn’t it? Paying attention to little details like that — having empathy for your userbase — allows creating what I call “intuitive” or “self-documenting” software.

Brace yourselves, 0.91 is coming

Oh, did I mention that Pitivi actually renders now? Well yes, that’s because we (especially Mathieu) have been doing a massive amount of work all across the GStreamer, GES and Pitivi stack to make this happen.
We have been incredibly busy in the past few months, pushing really hard to finally get a release out of the door by the end of the summer. In recent times, we have committed around 250 changes in Pitivi, 180 in GES, and I don’t know how many hundreds in GStreamer. My spare time was spent swimming through emails, having many technical discussions on IRC and dealing with hundreds of bug reports/issues/TODOs.

With a few issues remaining (mainly related to scaling in videomixer), we’re now at the point where stuff… works. Audio mixing and video compositing are back (and keyframable), effect properties are keyframable, deadlocks and crashers are pretty much gone (as far as we can tell), etc. I’m starting to run out of bugs. Amazing!
We can finally make an alpha release in the near future.

How you can help with 0.91

0.91 will be our first alpha release based on GES. It’s a very exciting release with many improvements, bug fixes and new shiny things. You can help by:

• Trying out the development version right now. Come have a chat and let us know how well it works for you!
• Documenting. The user manual is quite outdated right now (it is still based on the 0.15 featureset). We need writers!
• Helping me prepare the huge release notes. If you’re crazy enough.
• Creating simple and lightweight test projects for Mathieu
• Helping with packaging efforts (ensuring this can be packaged nicely, fixing build/setup issues etc.). Two issues you can tackle immediately are:
  • The port to Yelp tools broke our make distcheck, and this blocks the release. Help!
  • We implemented the AppData spec but we use INTLTOOL_XML_RULE — please provide us with a patch to make it work with itstool instead. I know nothing about this stuff.
• Revising the existing bug reports and doing a big triage cleanup
• Hacking! As usual, we’ll be happy to help you get started.
• Spreading the news