Yes, ladies, gentlemen, and seemingly-dead plants, it’s happening: after over 10 months of incremental work from the community, we are now releasing version 0.6 of our favorite personal productivity app, Getting Things GNOME. This release comes with some new features, lots of code improvements, many bugfixes and UX refinements (I am told that the “Better procrastination button”, presented below, deserves a place in the Museum of Modern Art).Continue reading “Getting Things GNOME 0.6 released”
This started out as a simple status report following my first report on the revival of the Getting Things GNOME project, but turned out into a full-fledged article that, I believe, would be relevant to many community managers and FLOSS project maintainers out there. Particularly if you have an established open-source project looking for sustainable development but don’t have the luxury of paid developers, it should be worth investing the 7-9 minutes to read this.Continue reading “Overhauling your Open Source project's "Developer Experience" and redefining the workflow”
J’ai découvert par hasard qu’on peut faire un clic droit sur le “profil” d’un périphérique dans pavucontrol pour renommer le périphérique. Or, cette fonctionnalité n’est pas disponible par défaut puisqu’il faut un module supplémentaire (sous Fedora, du moins). Pour faire un essai en temps réel:
$ pactl load-module module-device-manager
“34”? Quelle drôle de réponse! Je présume que ça veut dire que ça a fonctionné. Si on réessaie immédiatement la même commande, on obtient:
$ pactl load-module module-device-manager
Échec : Échec lors de l'initialisation du module
Ce qui, si on pense comme un développeur un peu paresseux sur la sémantique, dévoile que le module est bel et bien chargé déjà.
On peut maintenant donner des noms beaucoup plus courts et pratiques à nos périphériques favoris. Par exemple, ma SoundBlaster au nom beaucoup trop complexe:
Ou encore mon bon vieux micro Logitech au nom tout à fait cryptique:
Côté interface, tout ceci est plutôt moche et difficile à découvrir, alors j’ai ouvert un rapport de bug à ce sujet. Ce qui est un peu dommage, c’est qu’on renomme ici les entrées/sorties (sources/sinks) individuellement, au lieu de renommer le périphérique matériel dans sa globalité. Aussi, les versions renommées ne sont pas prises en compte par les paramètres de son de GNOME Control Center.
En tout cas, après ce test concluant, on peut ajouter les lignes suivantes dans le fichier ~/.config/pulse/default.pa pour rendre le changement permanent (je préfère éditer ce fichier dans mon dossier personnel plutôt que le fichier système “/etc/pulse/default.pa”, pour que ça persiste après des “clean installs” de distros:
Note: “default.pa”, contrairement à daemon.conf (dans lequel j’ai simplement mis “flat-volumes = no” pour revenir au mixage à l’ancienne), n’hérite pas automatiquement des paramètres système, c’est pourquoi j’ai inséré la ligne “.include”.
Cleaning up my apartment today, hoping to get rid of a pile of draft papers that has been cluttering my space for six months, I’m taking the opportunity to write about what this particular pile of paper means (yes, my blogging backlog goes that far—I am draining the swamp one post at a time!)
For the longest of times, as a designer flying under the radar (my management and marketing work is more “visible”, ironically), I did not have a proper portfolio. In fact, I had made a portfolio only once in my life, assembled in a few days in 2011. While my work as idéemarque in the past few years has led me to do a fair amount of design work, I was so busy with business work in general that I never took the time to do the massive amount of research and planning required to make a new one.
In early 2016, I finally sat down and made a new portfolio. Those who have worked with me know I’m a perfectionist, and since I had finally set my mind on doing this, I would be doing it right. It indeed took me 2-3 months of research, writing, designing, revising, redesigning, print testing, revising again and fixing issues, until I ran out of issues to fix.
From the start, I decided that it would be a top-quality print-only edition. I used beautiful, legible and readable fonts to make reading on paper a delightful experience. I invested in premium quality paper (including some semi-transparent sheets) and used a high-end printer, but not a commercial printing press as that would have been ridiculously expensive and inflexible for printing only a handful of custom-made copies. A print shop couldn’t have provided all the fancy features I required anyway (fancy binding, specialty paper, embossing, etc.). Therefore each of my portfolios is a hand-made craft—even if it might not seem that way as I made it full bleed (edge to edge). This whole project made me learn way too much about troubleshooting printer color problems, printing on unconventional paper types, faking bleeds, and the traditional bookbinding techniques of my ancestors.
In 2016, a printed portfolio might seem outdated compared to an online portfolio. Yet, mine is designed for print, precisely because the web and cheap emails have become the norm in this era of constant noise, and because I prefer to control everything in the reader’s experience—including the delivery, the typography, the texture, size, depth, resolution, and the physical (and mental) weight of the document. And not having to “/%$?%*)&!?” around with CSS and “modern” web development is a huge plus.
Some said, “How can this be such an involved process, taking you months?” to which I replied that, among other things, the document was roughly thirty pages. This got me some expressions of bewilderment, until I explained, “It’s not a graphic design portfolio, it’s a human-computer interaction design research portfolio.”
While it took a long time, the project was worth it, both as a personal challenge and from the reactions I got afterwards.
I have now decided to remove any traces of my portfolio from my website (except the photo and illustrations gallery). A website is not only a pain in the ass to maintain regularly, it’s typically ignored or skimmed anyway (basically, Schrödinger’s Visitor). For those who requested an electronic version of my portfolio over the past few months, I have insisted on shipping them the print version instead—tailored for them, of course.
Thanks to GNOME, we will be able to get some reinforcements for Pitivi this summer.
We’re very pleased to have Lubosz Sarnecki making a comeback! In 2011 he implemented the cairo-based clip transformation (zoom/resize/crop) feature in the viewer. Lubosz is quite experienced with OpenGL, Blender and GStreamer, as you can see on his blog and the variety of projects he contributes to.
This year, his project is:
- Evaluate the need for an OpenGL-based Ken Burns effect in GStreamer, vs an approach combining the CPU-based transformation plugins (videocrop, videoscale, videorotate and videomixer).
- Resurrect and extend our clip transformation user interface in Pitivi, to support rotation and animatable properties.
- Implement a color picker and custom chroma keying UI.
Here is a fun example to illustrate why software development in general is a complex endeavour:
- You think you’re going to fix a tiny problem: “hey, maybe we could make ‘s welcome dialog look a bit nicer“.
- Eventually, someone proposes a design or idea that looks interesting, and you realize that to truly realize it, you should also implement an audacious new feature: a way to visually represent an entire timeline as a thumbnail (that one is an open question, by the way; if you have some clever ideas, feel free to share them)
- …and to display new feature B properly, you should also consider—ideally—being a good citizen and implementing feature C upstream, in the toolkit you use instead of doing your own thing in your corner.
This kind of serendipity and interdependence happens regularly in FLOSS applications like Pitivi where we prioritize quality over “meeting shareholders’ deadlines and objectives”, which is why we sometimes take more time to flesh out a solution to a problem: we aim for the best user experience possible, all while negotiating and working with the greater software ecosystem we live in, instead of silently piling up hacks in our application… and we depend on the involvement of everyone for things to progress.
Since my previous technical update in January, I haven’t had time to touch Pitivi’s code. Thankfully though, Alexandru Băluț has been filling the gap with a ton of refactoring work: around 150 commits! That took a fair amount of time to review and merge, believe me. Besides code cleanup, he also finished the port of the viewer to a cluttersink, fixed fonts and theme colors detection for the timeline (so it looks fine even if you’re not using the Adwaita GNOME theme).
Alexandru took the opportunity to not only fix some bugs, but also do some visual refinements on the timeline ruler: it now shows hours and miliseconds only when needed (depending on the zoom level) and subtly grays out units that did not change from one “tick” to another, so your eyes can focus on what actually changed:
More interestingly though, with the limited time available to me, I helped prepare Pitivi’s 2014 fundraising campaign. It involves a huge amount of groundwork from an administrative and marketing point of view. It’s been months in the making.
- I’m glad that Mathieu and Thibault were able to spearhead the work of setting up the infrastructure, preparing the majority of written materials and setting up their legal and financial relationship with the GNOME Foundation.
- Huge props to Fateh Slavitskaya and Bassam Kurdali for the great work they put into making the fundraiser video (I’m a filmmaker, believe me, I know how hard and time-consuming it is to get this done right, especially when you have voice-overs and 3D animation involved. Oh, and all the editing was done with Pitivi, VFX with Blender). Thanks to Thomas Vecchione for cleaning up the voice recordings and doing proper sound mixing for the video, I definitely can hear the difference.
- Thanks to Oliver Propst for drafting initial contents for the FAQ and various emails that we had to send for outreach! It is always easier for me to start from existing contents rather than stare at a blank page (you could say I hate reinventing the wheel 🙂
Besides catching a cold and shovelling snow, this holiday season I spent some time scratching itches in Pitivi. For starters, thumbnails generation: if you’ve been using the new Pitivi, you certainly ran into this:
As you can see, thumbnails were not necessarily being shown for all clips. That was not the result of a buggy algorithm or anything like that (I don’t code often, but when I do, it’s perfect, of course), simply the fact that my solution for bug 432661 was partial: it would fetch the thumbnails if they already exist, but not create new ones.
Well, this is solved now. No more need to browse the folder with Nautilus to generate thumbnails! This does not block the user interface, thanks to Alexandru Băluț who helped me finish the job by correcting my incorrect attempt at threading with his own implementation.
The only downside of the threaded version is that you lose the simple benchmarking system I had put in place, but no matter: I’ve measured the numbers already, so let me share them with you.
As you know, I’m pretty adamant about maintaining good performance and responsiveness in Pitivi, especially for operations such as importing clips or loading projects. I know that iconview can be slow, so my commit (before Alex’s changes) had various timers to check if searching through the iconview or updating its items was a significant performance problem. I tried with two scenarios: importing 68 clips to thumbnail, and importing 485 clips to thumbnail. Here are the resulting processing times in seconds:
|68 thumbnails||485 thumbnails|
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
If you’ve tried rendering projects with Pitivi 0.15 or older, chances are you’ve encountered one of these dreadful situations where the rendering process would get stuck:
- …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.