Background
I use open source software every day on all the computers I own. In fact, outside of work environments where Windows is still predominant, very little of the software I use is closed source these days. As a result, I've wanted to contribute back to the community that has developed such great software by fixing bugs and implementing new features. However, I've found it a lot more difficult that I expected. To make any meaningful contribution, the project I would contribute back to had to be a piece of software that I used regularly. When I look at the ecosystem of software I use regularly, they are either written in C, a language that I haven't programmed in for 20 years (assuming the stuff I did at university actually counts) or they are extremely complex, or both.
Then, a few months ago, I got wind that one of the planned changes for Ubuntu 10.10 (Maverick Meerkat) was to replace the default photo management software: F-Spot was out, Shotwell was in. Photo management has been a sore spot of mine for ages on Ubuntu. None of the software that was available until now actually met my needs so I ended up not using any photo management software and doing everything through the file manager. Looking into it, it looked like Shotwell was the ideal opportunity for me to get a photo manager I liked. Shotwell uses Vala as a programming language, which I found intriguing and which I thought should be easier than C to get into.
Baby Steps
So I downloaded the source from the SVN repository, built the software and lo and behold, the build was actually easy and 10 minutes later I had a local version of Shotwell to play with. I then had a look at the source code and found it very easy to understand. So I thought: let's see if I can fix an easy bug!
For that experiment, I choose a bug that looked extremely easy: bug 1954 looked like the ideal candidate because it merely consisted in adding a line of information to an existing window in exactly the same way as the other lines already present in the window. And indeed, the fix was trivial. So I created a patch and uploaded it to the bug tracker.
What happened next was very important and is something that all community projects should be very attentive to: I got some feedback on my patch within a day, basically saying that the patch had now been committed to trunk with a minor modification. This is extremely important and is something the Yorba team, who produce Shotwell are very good at doing: all contributors are welcome and any contribution, such as suggestions or patches, are acknowledged very quickly. From a contributor's point of view, it means that you know that you can really participate and help the core development team improve their software.
More Complex Bugs
Quite chuffed by the outcome of my first bug fix, I decided to use Shotwell extensively and try solving more complex bugs. I eventually hit a significant issue with my SLR camera, which I duly reported in the bug tracker and which I decided to attempt to solve. It took a bit of time but I eventually got there and as a side effect actually solved another bug: result!
A Whole New Feature
By now completely sold on Shotwell, I wanted to do my bit so that it would be well received by Ubuntu users. In my mind, the most important thing was to ensure a smooth transition from F-Spot to Shotwell and indeed the migration was one of the major requested features in Launchpad and very high on the Yorba list too.
Implementing such a major feature can feel a bit daunting at first but, at the end of the day, integrating and migrating from weird and wonderful databases is something I get involved in on a regular basis in my day job so bringing that experience to Shotwell sounded like the way to go. And to be honest, the F-Spot database is extremely simple compared to some of the horrors I've faced recently.
It took a bit of time and I learnt a lot about Vala and the GObject library in the process. Thanks to the support from Jim and Adam from Yorba I got there in the end and finished the bulk of it in the middle of GUADEC. A few more extra tweaks were required but it's now in fairly good shape, ready to face the hordes of new users that Ubuntu will bring it.
There you go, that was my first major contribution to an open source project and I'm now hooked so will endeavour to contribute more.
12 comments:
I love you and want to bear your children.
No seriously. Thanks for the post!
That's a really great, very encouraging story! Thanks for contributing to Shotwell - as a user, I really appreciate your work :)
Thanks for the F-spot migration tool, without it many F-spot users would hesitate to switch.
Really cool. I currently use Picassa, but it would be great to switch over to something more Ubuntu Friendly. Maybe I'll look into doing for picasa what you did for f-spot.
Thanks for the insentive
Inspiring!
Thanks everybody for the comments, it's good to see that this feature will be useful to users!
@AK: that would be great if you wanted to do the same for Picasa! When doing the F-Spot import, I created a set of generic classes and a simple plugin mechanism in order to be able to easily add the same feature for other photo apps. So adding a new one is just a case of implementing a few interfaces and registering the new driver.
Hi, congratulations to your great tool!
Here's a question from my side:
- F-spot has this lovely timezone bug, which "corrects" the exif data to something wrong.
Is your approach working around this annoyance? - Or should I stick to re-importing the large collection from scratch?
Regards,
Marcus
@Marcus: I wasn't aware of that F-Spot bug so the import doesn't attempt to correct it unfortunately.
Hi, thanks for your work! Have you (or others) done any further work on Picasa imports to Shotwell? My wife has managed tons of Photos with Picasa, for years, and we're trying to migrate to Shotwell. In particular, there are lots of captions that we don't want to lose. Any recommendations would be greatly appreciated. Thanks again!
Jamie, there was an attempt at importing Picasa .ini files, as shown in ticket 1930 but it looks like it didn't go very far. It also looks like it was tagging itself on the file import mechanism rather than looking for the main Picasa DB (if such a DB esists!) which means you had to know where you photos were.
The most difficult part in doing such a data import feature is usually not in the programming, it's in finding how the source application stores and encodes data so the first step would be to understand what files are created by Picasa. Step 2 would be get examples of such files to understand their format.
If you want to help with the ticket, maybe you could do step 1. The way I would go about it is:
Create a new test user on a machine that has Picasa installed;
Log-in with the test user and create a time reference by typing the following in a terminal:
touch reference
Add a few pictures in the test user's home directory;
Start Picasa and let it import the pictures;
Add some meta-data to the pictures;
Close Picasa and check what files were updated by running this in a terminal:
find . -newer reference
You can then post the output to the ticket and we can take it from there. It may take time to get the feature complete but that would get it started.
Bruno: Thanks for the helpful and detailed reply. I'm a bit swamped with work right now, but I will try to provide those details to that open ticket. Also, I did later discover that Picasa seems to save the captions with the image file itself (EXIF tags, I assume, because I can see captions in image file properties from Nautilus file manager on Ubuntu). Thanks again!
Post a Comment