A typical day in my life as of late

I will cover the following from a very high-level view (I’ll have to make separate blog posts to cover them in detail, there’s too much to say):

• The state of our multimedia stack
• Our new timeline canvas and how you can help
• This year’s accepted Summer of Code projects
• Upcoming GUADEC presentation

Also, a small announcement: for those who also want some shorter, less formal status updates and occasional feedback probes, you can look at the new PiTiVi G+ page.

Clutter timeline canvas

In preparation for the Summer of Code, but mostly just to help us and demonstrate how much of a badass he is, Mathieu Duponchelle killed our goocanvas-based timeline and redid the whole thing with Clutter. In two weeks. This is what it looks like at the moment:

The state of our multimedia stack

We fixed some initial bugs in GNonLin in Milan. Since then, further investigation revealed that most of the issues we are encountering are actually generic bugs in GStreamer. Mathieu is now working full time on fixing bugs everywhere in the stack. We hope to have something showable (beta) for GUADEC and a release this fall — as you can imagine however, I’m unable to make solid promises at this point.

There are still many things that we need to rearchitect in GNonLin, but that’s a story for another blog post.

We recently started using Github’s bug tracking tool to keep a more easily manageable list of issues we have to deal with in the development version. Please note:

• This is not a replacement for GNOME Bugzilla. It is meant as a temporary measure for our extended development version, for stuff that is too small, fluid or uncertain to be filed as proper bug reports. Once we release, we’ll move remaining issues to Bugzilla. Upstream issues in GStreamer, once properly identified, are always filed in GStreamer’s (GNOME) Bugzilla.
• We welcome your help in fixing or investigating these issues. There’s also an “easy” tag for those of you looking for bitesized stuff.

Stuff you can fix in Pitivi, right now.

If working on GStreamer and GES is not your cup of tea, we still have a ton of fun little projects for you to do on Pitivi itself, including:

• A bunch of little nitpicks/papercuts for our Clutter timeline
• During the port to Clutter, Daniel Thul helped Mathieu by rearchitecturing and fixing the timeline clip thumbnailer module. It works, but there are some remaining, significant performance issues. This is a great project if you’re looking for finite, concrete, self-contained work to improve performance with a very highly visible impact on the UI. You would get a ton of love points for this.
• We have a title editor UI, but it needs some love. You don’t want us to ship with an unrefined UI, do you?
• UI tests!

This Summer of Code’s projects

We have four students working on Pitivi this summer, thanks to GNOME kindly offering us an extra slot to be able to achieve our mission. Here’s our ambitious list of project goals:

• General bug fixing in the entire GStreamer + GES + Pitivi stack, to be able to make a Pitivi release.
• Motion ramping (keyframable fast/slow motion, allowing the speed of clips to be changed over time, ideally with smooth frame interpolation)
• Finish the enablement of our new timeline layers management UI
• Reimplement audio waveforms. Better, faster, stronger.
• Video compositing
• Proxy editing. I’m currently writing a design and API requirements brainstorming page to help plan this feature. I will share it in my next blog post, where I’ll present some of the dilemmas I’m encountering (particularly around codecs).

Presenting at GUADEC

Come to GUADEC and attend my presentation at the beginning of August. Plans are a bit fuzzy for the time being, but you can expect my typical award-winning presentation style. Also, as usual, we’ll be having a Pitivi hackfest there. Czech it out.

• …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):

One way to look at things is that there is no such thing as a PiTiVi backend anymore. PiTiVi is a frontend that pushes the latest and greatest open-source multimedia technologies forward.

With the GES port nearing completion, this is the first time that we can truly say there are three interrelated components to contribute to. This new reality sets the tone for a different way to look at PiTiVi project ideas this year: you can finally…

Choose your character class

Are you a ninja? A spellcaster? A tank? While most projects are a balance of backend and UI work, we know that some people prefer to lean more to one side or another of the continuum — that’s why I created a new visual notation for our ideas page this year. Instead of an “easy/hard” system (which would be inaccurate and misleading, as perceived difficulty is measured differently for everybody), we simply provided a visual indication of the expected involvement in the various components for a given project idea (for example, “PiTiVi: ◼◼◻◻◻ GES: ◼◼◼◼◼  GStreamer: ◼◼◼◻◻”). So if you were looking for something closer to a hardcore GStreamer GSoC project, you can spot ideas that might interest you here.

Not a programmer? You can help raise awareness about this. Maybe you know a brilliant hacker friend/relative or a top-notch computer science student waiting for a chance to make a big difference in the world. Tell that person about how cool and welcoming PiTiVi is and how getting involved is the best way to advance free, powerful and intuitive video editing for everyone!

Edward provided an initial patch to improve the behavior of timestamps and seeking in GNonLin, while Nicolas “Stormer” Dufresne fixed two bugs causing deadlocks. Nicolas spent a lot of time discussing with Wim Taymans, Edward Hervey, Sebastian Dröge and other hackfesters about the architecture of GNonLin in light of GStreamer 1.x. He also fixed looping for the Ogg demuxer in pull mode and, with some help from Mathieu “Forest Ranger” Duponchelle, fleshed out the design for a new tree data structure for GNonLin.

Mathieu the Moustached Avenger worked on implementing keyframes in GES, paving the way for him to create a user interface to animate any effect property in PiTiVi. That user interface will most likely depend on him working on the clutter timeline canvas, so I’m looking forward to improvements in that area.

Thibault “Keyboard Crusher” Saunier finished the implementation of GES Containers and clip groups, then worked on implementing — at long last — audio mixing in GES. This is an essential feature of multitrack audio/video editing, and I’m really happy to see that feature make its comeback for the next release of PiTiVi. This work will also depend on Mathieu’s keyframes UI. A proper reimplementation of video mixing remains to be done, however.

There are lots of outstanding things to solve in GNonLin and GES. Nicolas has a bunch of ideas for things to improve and redesign in GNonLin and I expect much collaboration between Thibault and him to optimize the entire stack for better reliability and performance (for example, adding caps filters to allow realtime downscaling of videos to improve preview performance, configurable downstream buffering for playback to avoid frame drops in CPU-intensive parts of a timeline, etc.). GNonLin and GES have much potential to allow us to be a lot smarter than before.

Personally, I spent most of my time testing, discussing and hacking on some new features for PiTiVi.

• I added a button in the timeline toolbar that toggles the “gapless mode” (automatic ripple edits), which makes your clips behave like magnets and prevents needing to re-arrange them manually all the time. The feature works and will be merged after a customary code review.
• I made some progress on the custom effects UI branch. Once it’s complete, you will be able to easily create custom user interfaces for effects that require it, simply by using a glade/gtkbuilder .ui file (or, if you prefer, a set of widgets from your own python module). Of course, for the majority of effects, our automatically generated user interfaces are still good enough, so we can keep using them and avoid unnecessary work.

(See my previous blog post for a situation report on where we stood with PiTiVi before the hackfest)

I also spent a bit of time setting up my film making gear and shooting various interesting moments of the hackfest. Here’s my montage, which will tell the story much better than a long blog post. Hope you’ll like it:

I would like to thank Collabora for allowing many GStreamer contributors to attend the hackfest, which I consider vital to the health of the GStreamer community. I was happy to meet again with many friends and help push the Free multimedia stack forward. Props to Christian Schaller and Alessandro Decina for organizing the whole thing, too!

Aside from Collabora and Fluendo sponsoring two of our dinners (thanks!), I would also like to thank you, PiTiVi supporters, for making it possible for me to spend some money to thank GStreamer contributors with some food and beer — maximum boost to the GStreamer community! Full disclosure: I used 84 euros worth of PiTiVi donations for that purpose.

Here’s a list of fixes in Pitivi since my last blog post:

• Fixes for our automated UI tests, including interaction with the filechooser dialogs, the spinbutton widgets (see this bug report), the typing speed, etc.
• Fixes and cleanup for backend tests
• Enforce unicode in preset names, preventing a bug with non-ASCII chars are used in the name of a preset
• Allow presets with “/” in their name
• Fix drag and drop from the media library’s listview mode
• Prevent playing back clip previews in double (that was a subtle one, since windows were exactly on top of each other)
• Make the media library clip previewer work even when the application is in fullscreen mode
• Make effect properties work again
• Take into account project settings in the main window when loading a project
• Conform to the new version of the Freedesktop specification for thumbnail directories
• Make special characters show up correctly in the media library’s iconview mode, remove the ancient filename shortening code and rely on Pango instead.
• Properly handle clip URIs encoding, ensuring that we can find the thumbnails for all files. Also do last-minute checks for that encoding before computing thumbnail hashes.
• Avoid excessive work when searching clips in the media library, improving performance
• Handle special characters in the media library’s search entry
• Force calculating the toolbar height at the last minute to properly handle all screen setups in fullscreen
• Scale down effects thumbnails to fit better in the new listview arrangement
• Fix a race between clicks on the preview widget’s slider and position updates. When using it in the media library/file chooser, the slider would often “jump” back to its previous position instead of seeking. The new behavior is now smooth and reliable.
• Ensure the welcome dialog is initially centered on its parent
• Bring back the checkbox to enable/disable effects
• Initialize GES to prevent a segfault from occurring on some machines at startup
• Make rectangle selection work again in the media library’s iconview mode
• Make the “Restore from backup” dialog modal to the main window

New features:

• Automatically adjust the zoom when inserting to the end of the timeline
• When the viewer is undocked, provide a button to toggle fullscreen mode
• New icons for split, group/ungroup and align
• Specify the duration of missing/moved files when prompting the user about their new location
• Update effect categories, merge “Noise” and “Blur”, add a “Compositing” category, categorize new effects
• Automatically save the last used render directory
• Stop rendering when the user presses Escape
• Use symbolic icons everywhere where it makes sense (in the media library toolbar, property reset buttons, lists, etc.)
• Use the system’s default image viewer to preview images from the media library
• Update the preview widget slider on a more frequent basis, giving it a snappier feeling
• Automatically save and restore the main window’s position. This is especially useful when using detached utility windows.
• Hide the effects toolbar when nothing is selected
• Add a contextual help button in the render dialog to explain container formats
• Allow entering a frame number into the time widget

Architectural changes and cleanups:

• Clean up the build, prune useless files, simplify and centralize the list of dependencies
• Refactor dependency checks to be more reliable and provide a faster application startup
• GES Assets (implemented in GES and integrated in Pitivi), including the notion of GES Project among other things. This paves the way to many other improvements.
• A revised and simplified API has been implemented in GES and integrated in Pitivi. You can see this new API online in the GES API hierarchy documentation.

So yeah, that’s the summarized version… with refactoring and cleanup all over the place, there’s more than a hundred commits (excluding translations).

Stuff that still needs to be done (as always, we need your help here):

• Need to refactor the timeline UI code and the clip transformation UI
• Undo/redo
• Improving/expanding the UI tests, see the test suite wishlist
• Figure out how to better integrate the “welcome dialog”
• Figure out how to shave off the menu bar and how GTK AppMenu will work with accessibility technologies (and Dogtail)
• Improve the title editor UI
• Improve the timeline thumbnailer
• Reimplement the notion of grouping in GES
• Reimplement video compositing and audio mixing. Properly. In GES.
• Make a new keyframe UI that doesn’t suck. Integrate it for audio volume curves and to provide animatable effect properties.
• Fix… all the bugs! _o/
• Insert your own itch to scratch here

Ongoing work in my own/personal repository:

• Custom effect UIs
• New high-resolution icon (pictured above), new mimetypes
• Automatic rippling
• Resurrecting the codecs installer

No, really! It’s an incredibly productive and motivating event to participate in.

One of the major items we would like to accomplish is to fix GNonLin as much as possible. As you know, the GStreamer 1.x series is a major departure from the 7 years old 0.10 series’ design, and GNonLin needs to be rethought for the new world order. The current state of GNonLin makes it impossible for nonlinear audio/video editing applications to behave properly in GStreamer 1.x. This affects Pitivi, Jokosher, Novacut, and perhaps others.

If you want to work on PiTiVi’s UI at the hackfest, you are of course welcome to do so. I always have nice projects to play with, such as the need for a new keyframe UI, fixing undo/redo, improving the performance of the thumbnail system, helping Pēteris with the GStreamer waveforms library implementation, or porting the timeline and viewer canvases to Clutter.

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!

However, after all these years, most of the blogs or news sites (including the most popular ones) still don’t bother checking for factual accuracy and just blindly accept what corporate press releases would have them believe. I would have thought they would have grown more careful with time, but the situation has generally not improved, to the point where I am now compelled to say this now, officially, in public: Lightworks is currently not open-source and never has been. Furthermore, if it ever is open-sourced, it most likely won’t be anywhere close to a truly open project.

From what I’ve seen by reading the comments on these articles, the Lightworks forums or elsewhere, it seems that those who point out the very issue that I’m about to explain are routinely labelled as ungrateful, arrogant freetards or considered trolls to be banned. It is my hope that you will read this blog post with an open mind, and that you might see where I’m getting at with the last section.

The source code that never saw the light

EditShare announced two years ago their intention to make Lightworks “open-source” someday, and that’s it. They have never released any source code since then. A code drop was planned for 2011 and it was postponed indefinitely. Calling Lightworks an “award-winning open-source video editor” currently is a lie. Even if they do open-source it someday, until the very day they do so, that statement remains a lie. Such a statement can only be a “truth” when you start saying it after the source code has actually been released under an open-source license.

Until then, you can’t simply trust a corporation on that promise without some cautious skepticism. They have a ton of business imperatives and constraints: the bottomline, strategic direction, competition, logistical and legal challenges, investors to answer to… and virtually no compelling reason to open-source their product (we’ll come back to that further below).

Although I do have some faith that they might release it eventually, personally, after two years of waiting, I’m even beginning to doubt that. I’m not saying that EditShare wishes to do evil or just throw a marketing ploy together; I heard the numerous justifications/excuses along the lines of “we’ve got bigger priorities”, “we have a reputation to uphold” and “we’re stuck in legal review”, I just don’t buy those arguments.

Anyway. Whether or not not you believe they will release the source code someday is irrelevant, that’s not the point I want to make here in the first part. The point is: until then, it should not be considered open-source and should be treated with the default assumption that it may never be. If you see articles spreading inaccurate statements along the lines of “Lightworks is an open-source video editor” or “Lightworks, the professional non-linear video editor that was open-sourced in mid-2010” (instead of “Lightworks is supposed to be open-sourced sometime in the next decade, according to press releases”), please comment and request the authors to correct or back their statements with references to publicly available source code repositories. We cannot stand by while untrue statements are being repeated all over the place, it is a disservice to the public.

What if they do release the source code then?

Most likely scenario: it won’t change a thing.

• It’s a million lines of code (compare and contrast)! Good luck attracting people to work on such a monster codebase with 20 years of history. Most of which has been on the Windows platform (some of which on DOS… before that, I don’t know). Those of you who have done software maintenance know what this means. If projects with clean, modern and simple codebases like Pitivi struggle to attract any developers at all, don’t expect a “community” of benevolent hackers to form around your project anytime soon.
• The open source version will be crippled. As far as one can understand from their communications and their pricing page(see the image further below), there would be three editions: the open-source edition, the “free” (freeware) edition, and the “pro” edition. Currently, only the “free” and “pro” editions are available. The open-source version probably won’t support anything but, say, Theora and Vorbis. It wouldn’t make sense to have the “open-source” version have support for the codecs that their “free” edition currently offers:
  

  The upper portion of the comparison table between the free and pro version

  • They can’t just bundle patented codecs for Free. Licensing those (if you can license those) is typically done on a “number of installations” basis and with limits on redistribution. You can’t do that with fully free and open-source software on which you have no control over.
  • They won’t switch their plumbing to use GStreamer or ffmpeg/libAV, for various obvious reasons (technical, manpower, QA, control, legal, etc.).
  • A significant part of their business model will be to differentiate the “freeware/premiumware” version from the fully “open source” (crippled) version. You want proprietary codecs? Pony up. This is how it works pretty much everywhere, and arguably, this is what their clients expect and accept. And that’s fine. As I said, it makes sense. For them and their intended clients.
  • Ignoring the whole codec issue for a minute, it is possible that the “open-source edition” will be only a portion of the application (ie: “crippled”). Anything that touches DRM, trade secrets, whatever, might be stripped out—it’s hard to tell currently, as no source code has ever been released. If the current differences in featureset between the “Free” and “Pro” versions are any indication, then this might be a real scenario.
• It won’t cater to those who want a simple, native application that is well-integrated with their desktop environment. Or those who want a workflow for on-set redundant assets management as their top priority (Novacut). It will only solve the problems of a particular niche.
• Community-wise: there are many ways Editshare can screw their community management (see further below).
• With all that in mind, it would be very surprising to see the open-source edition start appearing in your official Linux distribution repositories.

I might add some amusing observations from trying the beta:

• You’re forced to accept a EULA with a restrictive (non-free, non-open-source) license, which just confirms my points above about the various “editions”. However, do take note that the Lightworks beta was explicitely not the “open source release”. Again, that’s not the license the open-source edition is meant to be released under. Nobody knows what the chosen license will be at this point in time.
• Lightworks is riddled with DRM and copy protections. It refuses to run in a virtual machine (such as VirtualBox) and cannot be run in a debugger (because it would be a threat to its copy-protection mechanisms).

Why would they even still care?

The typical Lightworks demographic usually doesn’t give a damn about the code being open-source. That’s secondary. They just want software that is reliable, efficient, supports their crazy formats, and is reasonably priced (bonus points if it’s free or very cheap, given the competition from other pro-level packages). “Open source”? Nice to have in theory, cool for bragging with friends at the pub, but not much else. Kinda like saying that you’re using a “green” product. The typical Lightworks user is never going to study or modify Lightworks source code.

With that in mind, what does EditShare hope to achieve? They’ll be lucky if they get more than two crazy geeks to hack benevolently on the code outside of their official paid developers. I know because I’ve dealt with open source projects for years, and even those that are incredibly well-managed and welcoming to contributors struggle to attract and retain them. EditShare is aware of this, and they express it with some snobbism (warranted, to some extent):

Of course users want software that’s written by us at this stage. Is there anyone other than the original developers of Lightworks, and the best of developers that have moved across to us from other products, who are better placed to move Lightworks forward? Of course there are great Open Source developers out there, but they would be working from a standing start.

This is a specialist and complex product. We are not going to release it to Open Source until it is ready. Do to otherwise would cause untold issues.

It is quite clear that they are expecting to shoulder the whole burden of development and maintenance. If someone else bothers to investigate a bug and send them a patch for it, they’ll certainly consider it, but I’d be surprised to see them giving “commit access” to anyone else than themselves (but hey, who knows). If my guess is correct, we’ll just be inheriting another Cinelerra (except that the base application is arguably of much higher quality this time).

Open-source “product” vs open-source “project”

This subtle distinction is probably only obvious to those who are familiar with the open-source ecosystem (don’t flame me for my choice of words here, I’m trying to be comprehensible to the average person!), but there are countless ways in which EditShare LLC can screw up their “community” before even considering technical details like the ginormous codebase. They can screw up their licensing, they can try to exert too much control over the direction of the project, they can do like HeroineVirtual with Cinelerra and just release a monolithic code drop every six-to-twelve months, they can do like Sun/Oracle did with OpenOffice.org, like Canonical with their copyright assignment clauses, like Google does with its “read-only” open-source development model for Android, etc. That’s just from the top of my head.

It’s not the first time we see a company try to “open-source” a product and mess things up. And so far, EditShare has had a terrible track record when it comes to communication, multiple delays and broken promises, and just being clueless about how to properly interact with the “open” world generally speaking: the fact that they hyped their upcoming Linux alpha launch for months and then suddenly revealed, at the time of the release, that they were releasing it only to a select few insiders… All that without foreseeing the harm it would do to their already strained relationship with the public? That’s just pitiful—and terribly far from Kdenlive, OpenShot, PiTiVi, and all the others whose development has occurred fully in the open from the start.

The greater ecosystem: being a good open-source citizen

An open-source project is not about throwing together a pile of code and slapping a copyleft license on top of it. It’s about a superior software development model (given equal manpower) where you foster reuse and collaboration with other open-source projects. It is about being a living cell of an organism, an active part of an ecosystem.

Lightworks might be released under an open-source license someday, but unless they rewrite the whole application (which would make no sense), it’s still going to be one monolithic “bundle everything, do everything in-house” piece of technology.

This has all sorts of technical implications I won’t be getting into. More importantly however, there are some absolutely crucial implications on the greater scale of the “Free Software ecosystem” that I must mention.

When you contribute to open-source projects that have been doing things “the open-source way” (that is: depending on shared libraries and contributing to them—be it testing or providing fixes upstream), such as Pitivi/Kdenlive/OpenShot/etc., you end up fostering the use and improvement of the technologies that are the heart and soul of your open-source desktop/operating system.

• In the long run, you end up improving GTK+, Qt, GStreamer, Webkit, Pango, FFmpeg/Libav, GES, MLT, Cairo, X/Wayland, goocanvas, Clutter, GLib, the icon themes and artwork… the list goes on.
• Recently, over the course of two months, Pitivi contributors have reported (and often fixed) more problems in GTK+, GLib and PyGObject than EditShare could ever hope to achieve in a lifetime—and that’s not even taking GStreamer into account.

Lightworks, as far as I know, doesn’t use any of these. Improvements you make there will not find their way to your desktop or mobile device. Whatever you do with Lightworks stays within Lightworks—and that’s it.

• Update: it is claimed in the comments below that Lightworks does use Cairo and Pango.

If you take “collaboration with the greater cause” out of the equation, one might argue that you could just as well have bought a package on the shelves for 80$ way back in 2003, instead of spending years hoping for an open-source “project” to solve your problem. Unsurprisingly, that’s what many people do.

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…