• …at the beginning, with the progressbar saying it’s currently “estimating” — which was a lie that I corrected a little while ago.
• …at the very end. Extra trolling points for having made you waste a huge amount of time to get a 0 bytes output file (if we’re lucky, that bug is gone).
• …somewhere in the middle, because caps negotiation failed, some elements were not linked, GStreamer thinks you ran out of available RAM, or because you’ve been very naughty.

In any such case, the rendering dialog just sat there and smiled at you, as if everything was fine in the world. Well, no more:

Pitivi is going to give you the honest, brutal truth.

This is the result of a horrifying thought suddenly springing to my mind yesterday night: “Hey, what if the code was not even checking for errors in the pipeline when rendering?”

Indeed, it wasn’t. How silly is that! I have thus prepared a simple fix to improve the situation: catch pipeline error messages, abort the render (you really don’t want to ignore a GStreamer error) and display an error dialog. This will at least let people know that something is wrong and that they should start writing patches to GStreamer instead of accusing Pitivi of hurting kittens. You’d be surprised how many people can sit for hours in front of that stuck progressbar.

Before I commit the fix however, I would need your feedback on the usability of that dialog:

This is not terribly pretty, but it’s better than nothing. A few things to consider:

• In that screenshot, all the text except the window title (“Error While Rendering Project”) comes from the GStreamer pipeline error message (the error and the error’s details). I know that the error details look ugly, but I suspect it wouldn’t be useful to GStreamer/Pitivi developers if we don’t have them “verbatim”. Maybe we could try to mangle the error details string (split using “:” and take only the first and last two items of the resulting list?) and encourage the user to run from a terminal to get better debug info, but that feels a bit backwards.
• We should probably have some less-scary text to accompany the actual error details. Something that guides the user towards an action that can be done to address the problem (ex: reporting a bug). Maybe it can be placed between the header and the details (above the “qtdemux.c” line)? The problem is finding a universal text to be used.
• If we consider the route where we suggest the user to report bugs, where should we point to? The Pitivi bugs investigation page? Pitivi bugzilla? GStreamer bugzilla? The distro’s bug tracker?
• Let’s keep this simple, both visually and in terms of code/implementation.

What do you think? Is the current approach sufficient or is there something better that we can easily do?

Update: here’s an alternative dialog with some more comprehensible text, where the actual error (as seen in the previous screenshot) gets shoved under the rug by putting it in a GTK expander widget (clicking “Details” reveals the error’s details as above):

The core feature was to watch webpages for updates: back then, I did not know about syndication feeds, and I was sick of refreshing ifolder.com every single day hoping for a release of the peer-to-peer version of iFolder (for which we still have no equivalent today).

But why stop there? Why not handle events such as new emails, network failures (in those days, I ran my web server on my flaky residential connexion), software updates becoming available, and so on? You can grasp the whole genius of the idea by looking at one of the first mockups I drew back then:

Some old-timers among you may have noticed a ressemblance with Beagle‘s old user interface — back when it was called “Bleeding-Edge Search Tool”. Aaah, another nostalgic memory of the Novell desktop days.

Specto taught me that even if you have an arguably brilliant concept/mockup, random strangers on the Internet won’t magically jump onto your bandwagon and write code for you. Once this “reality check” finally set in after a couple of months, I took the dive and taught myself Python programming. Specto holds some sentimental value as it was my first OOP learning platform, but I’d probably be horrified if I were to look at its code now, after having considerably improved my skills by contributing to Pitivi. How the hell can Specto have nearly as much code as the current Pitivi development version, anyway!?

But I disgress. Where was I? Ah yes.

GNOME 3.6 made it all obsolete — finally.

The thought struck me recently: the user experience provided by GNOME Shell’s notification system is exactly what I needed all along. It fills my desire to have my computer patiently wait — like a tireless companion — for my return, without worrying about missing events.

If someone had shown me GNOME 3.6 in 2005, I would not have believed it. And yet, with the gradual changes in the 3.x series, we sometimes forget how fantastic the whole thing is.

Even with my heightened expectations, I was still impressed to see that I could now pick up calls even if my home desktop computer’s screen is locked! A real technological delight.

For watching the Web, Specto is now mostly irrelevant: Liferea is the program that took its place in my life. Arguably, social networks have also filled that role for many people.

Sometimes, the software you created becomes irrelevant and you find that to be a good thing.

Following up on my previous announcements where I called for a new maintainer and subsequently decided I wouldn’t touch anything without a patch, I can now say this in light of GNOME 3.6: Specto is dead. I don’t care about it anymore. Of course, if someone wants to take over maintainership/direction of the project, I’ll gladly give that ability to you.

When people trash the work you’ve been doing fully in the open for over a year and almost nobody stands up to defend you, you have to have a really tough skin. I can afford to read those articles with no ill effects because I have an emotional distance from the matter (not being closely related to the project, except in spirit), but otherwise, you have to swallow tears and quietly breathe fire in lieu of ragequitting, and continue improving your software for the next release. With the side-effects on user expectations from such a long development cycle, you start brainstorming ways to adapt the cycle to prevent such events from occuring again.

And yet, I’m sure there are many who are quietly happy or optimistic about the progress being made. I, for one, would like to focus on one particular aspect where my quality of life improved significantly with the new installer. Thanks to one of my favorite heroines and the hard work of the Anaconda team, the Fedora installer now allows you to set up your system with any keyboard layout supported by X.org. As usual, all it took was a crazy belgian pirate to stir things up.

As I’ve been waiting for a long time for this, I appreciate the work that has been done towards this goal. I’d like to thank Máirín for the research/followup work she did on the matter to ensure we could all switch to French Canadian Dvorak for F18. Now that is what I call customer service :)

By the way, if you care about usability/UX and haven’t added Máirín’s blog to your feed reader already, do it. Do it now. The posts in the Anaconda category are especially interesting for those who are willing to understand the long and elaborate design process that led to the new Fedora installer.

In this screenshot, I used a gray gradient as a my desktop wallpaper (for simplicity)

I’m also quite happy about a very nice contribution from Elad Alfassa to polish the rendering user experience. When the window is not currently focused, we now show a notification and play a sound (when pycanberra is available—where’s my introspection?) to tell you to put down that webcomic you were reading:

…and he reused the progress dialog to allow launching playback of the resulting file in your favorite video player:

There still is, of course, room for improvement in that progress dialog in general. I need to think about it a little bit, but feel free to offer suggestions or patches.

Other little things that have been fixed in Pitivi in the last few weeks:

• Activating (pressing the Enter key) the filename entry in the render dialog starts the render (for those who don’t care about rendering settings!)
• The timeline toolbar is now vertical and sports a slightly improved “Split” icon. It also does away with obsolete buttons. Hopefully, better icons for (un)grouping are on the way.
• Dogtail UI tests have been fixed.
• Tests for presets were improved and cruft from old integration tests was removed (about 1400 lines of code), thanks to aleb.
• The “contributing” page on the website has been reworked a bit to be clearer.
• The code now passes the 1.3 version of the PEP8 code style compliance checker.
• The clip previewer now works correctly while in fullscreen mode.
• I hear it can now be launched on FreeBSD (apparently we’ve got at least one such user :)
• The previously mentioned filtering in the import dialogs has been improved to use the system mimetypes instead of file extensions.
• The media library keeps itself sorted alphabetically as you import files (thanks to Alex Băluț), without any additional performance hit. It is possible to confuse the sorting a bit if you mix ascii filenames with japanese lolcat videos, but even a human would have trouble knowing which goes first in that situation.
• Various improvements have been done on the build script. It tries to avoid building glib, prefers building stable releases instead of checkouts of “master” everywhere, and is generally more resilient to failures. If you still experience issues with it, patches welcome!

It is very hard to find any relevant prior art that could guide me for this metaphor (most applications don’t have icons for these, they are only available through menu items). Inkscape can get away with icons that show “drag handles”, but we don’t have those in Pitivi. (un)grouping is quite an abstract concept, given that it does not visually change the clips in any way, it just changes the way they react to selections.

The last two items in the image below are the current group/ungroup icons:

Here is my attempt at making new ones with clearer meaning:

What do you think? Do you have better ideas on how to represent this?

Note: the icons I made are pixel-perfect, the 1px black lines above the icons are not my fault (I think). GTK seems to add some sort of shadow, probably because it expects symbolic icons in that toolbar (but I can’t imagine a way to represent clip interactions without color).

No jokes. Even after simplifying and compacting the code, it’s still such a pain for me to navigate through C that I actually felt the need to output the code onto thin slices of dead plants and stick them to a wall. This piece of code that I wanted to understand for a long time suddenly became clear after a few hours of analysis with a blue “thinkpad” and ballpoint pen:

And that was just reading and annotating… imagine if I actually had to write that code.

What was this code for, you ask? Making the toolbar hide nicely in fullscreen mode. Thus 400 lines of compacted C code to analyze from Gedit (nearly 700 if you don’t compact and just search code related to the fullscreen toolbar) became 50 lines of Python code in Pitivi.

Okay, the fullscreen toolbar is not the only thing I’ve been up to lately. While cleaning up code or looking at old bug reports, I fixed some little details, such as filtering out unknown/irrelevant file types from the file chooser dialog when importing clips:

A combobox (defaults to “Supported file formats”) allows you to change the strictness of the filtering. The same is true of the “missing clips” file chooser. By default, we now show only files with the same extension as the one you’re looking for:

I also made it error out if you don’t provide the requested replacement clips, with a new error dialog to explain accordingly:

This is better than being stuck inside an infinite asynchronous loop, trust me. There are also some new error dialogs (everyone loves those) to catch some silly corner cases, such as trying to save in a read-only directory (because GTK doesn’t do it for us):

…And even crazier scenarios, including someone explicitely bypassing the file extension filters to try to load a movie file as if it was a project file:

It’s the little details that count. You can’t make something too bullet-proof.

I also progressively reworked the pitivi git environment/build script to make it smarter and friendlier. Not only does it allow you to continue where you interrupted the checkouts/builds, but it has a built-in debugging duck:

“What, that’s it? Don’t you have more exciting stuff to show?”

Well, it turns out that Pitivi itself is pretty much ready*, it’s in very good shape. What’s preventing a release is the need for GNonLin (and after that, GES) to be fixed, and there’s nothing I can personally do about that (except testing and mentoring interested contributors). So if reading and writing C does not require you to stick pieces of dead plants onto walls, come talk to us!

*: except if we embark on the project of refactoring and porting the whole timeline UI to Clutter… Oh, and we need someone to fix undo & redo after that… And expand our test suite… And improve our title editor UI… And update the user manual/documentation…

• Cleanup the code for gtk actions so that the code is more readable and robust, fixing 629208 in the process.
• Cleanup the menus (again).
• Avoid having the viewer eating the CPU while idle.
• Fix various problems such as “Select unused clips” not working in treeview mode or reimplement removing all timeline instances of a clip when removing it from the media library.
• With the help of Brian Grohe, merge and delete spam user accounts on the wiki. I only have to fix image uploads and the https certificate issue now.
• Start fixing 629855; see below for details.

It turns out that pitivi was secretly writing autosave/backups of your project files (and deleted them when successfully saving/closing), but it did not actually use them. You’d have to know they exist, when they exist and where to find them, which is hardly intuitive.

So, I set out to fix this. Along the way, I ended up making the “unsaved changes” dialog more helpful. This is the result:

Then I worked on the actual dialog to prompt the user about the existence of an autosaved project file. It uses uses the same mind-blowing human-readable time formatting nekohayan technology, as you can see in the various following scenarios:

If you ignore the backup file, it will obviously be deleted when you cleanly save/close the project.

The big question is however, what we should do if the user selects to restore from backup:

• Should we simply rename the backup file to overwrite the “old” project file and then load it? This would mean the “old” project would be lost. In theory nothing should go wrong with that…
• If we want to be paranoid perhaps we could load the backup file as a temporary file and force the user to use “Save as” instead of a regular Save, but I’m not sure if that’s what users need. Thoughts welcome on this one, but I’d really like to have a simple solution.

org.gnome.*, org.gtk.*, ca.desrt.*, org.freedesktop.* … okay, I get that those are meant to look like reversed URLs, that part makes sense… but not as much when you have desktop.gnome.*, desktop.gstreamer.*, apps.*, a11y.*

Here comes the  fun part:

• Why is gnome-shell in “apps” but not in “org.gnome” like most of the other core apps? …oh wait yes it is also there, but this time it’s named “shell”!
• Why are “proxy”, “smb”, “webkitgtk” and such present in “system” whereas “power-manager”, “packagekit”, “login-screen”, “bluetooth”, “screensaver” are not?
• org.gnome.desktop.a11y exists (just to complement the toplevel “a11y” tree, you know), just as org.gnome.desktop exists to complement desktop.gnome
• Etc.

Where is the consistency and how are users and developers expected to know where to find what? I must be missing something (except aspirin)… please enlighten me.

The fact that you would need a search interface is a bad sign. Just try to find how to reset your font settings in less than two minutes and twenty clicks, I dare you.

I believe you should provide your developers with the fastest computers to do the development, and five years old computers to do the testing. I therefore do my benchmarks on three computers:

• Kusanagi, my most powerful computer, equipped with a solid state drive and a Core2 Quad processor, 4 GB of RAM
• Kuze, a six years old Thinkpad T43p, with a conventional IDE hard drive and a Pentium M processor (single core), 2 GB of RAM
• Krimson, a modern laptop from 2009, with a conventional SATA hard drive and a “Pentium” SU4100 (dual core) processor, 3 GB of RAM

I won’t bore you with the details/show you my wall of numbers and measurements, I’ll summarize everything by this pretty graph comparing before/after:

Startup times (in seconds, until the user interface shows up) were measured with a stopwatch, so expect a margin of error of 0.3-0.5 seconds, but my measurements are pretty reliable (having done them multiple times).

Cold startup times are done by flushing the kernel caches (echo 3 > /proc/sys/vm/drop_caches).

I thought Benjamin’s idea of launching gnome-control-center afterwards (to simulate real-world cold startup times) was clever, and so I re-ran all my benchmarks with it. I’ll refer to those as “lukewarm” startup times (maybe someday I’ll be known as the guy who was crazy enough to coin that term). I do think the best indicator of real-world “frustration-inducing” startup times would probably be the “lukewarm” values (rather than an absolute cold start or a warm start).

In the 0.14.91 pitivi pre-release, we shaved off roughly 2 seconds of startup time compared to 0.14 (thanks to Alexandru’s hard work). As you can see, there’s still room for improvement, but optimizing the startup times of a complex application with many checks and dependencies is hard.

I willingly left some data out (from experimental optimization branches and such) to keep things simple (and accumulated gains of 0.3 seconds don’t make that much of a difference at this stage), but I’m guessing that one of the culprits is the fact that we do a lot of stuff in pitivi/check.py on startup (disabling checks entirely, on Kuze, shaves off 4 seconds cold/lukewarm and 1 second warm). The thing is, those checks are necessary to ensure that pitivi has at least the minimum to actually work properly (though maybe some of those checks could be reevaluated)… and what is the point of showing the user interface quickly if you can’t actually run the app because you don’t have cairo, the proper version of gtk, goocanvas, gnonlin, and so on?

One could argue that we should simply show the main window, then run the checks and present the user with a dialog listing everything that’s wrong… but how is the user experience expected to be in that case?

But check.py may not be the only thing. We may be doing something really stupid. Take a look at my bug report and help us investigate this. I have a nice cProfile output with its pretty graph telling you where most of the time is spent during startup.

Now, it shows up like this, finally making use of your screen’s vertical space:

Also, Richard has made my day when I suggested that the version numbers be a little bit less prominent in package lists (to reduce visual noise) and he Just Friggin Did It™. Thanks!