Category Archives: Hacking

Announcements, Hacking, Shotwell

Publishing is Ready for Prime Time!

Leave a comment

With the release of Shotwell 0.6 coming up, we’ve started the process of updating documentation. In addition to Shotwell’s familiar user documentation, which Allison has been diligently cranking away on to great effect, there’s also the Architecture Overview, a technical document that describes Shotwell’s underlying design. Of more interest to programmers than users, the Architecture Overview is the go-to document for understanding how all of Shotwell’s pieces fit together. Because I wrote a lot of the publishing subsystem, it fell to me to document it for the Architecture Overview. And as I was writing up my description of the publishing subsystem’s design earlier today, I realized something: publishing is ready for prime time.


What I mean by this is that if you’re a software developer and there’s a web service you’d like to publish photos to that’s not supported in Shotwell right now (SmugMug and Zooomr come to mind), then building support for it into Shotwell shouldn’t be too hard. There is one major caveat: the service you’re interested in supporting must provide a REST interface. But if that key requirement is met, you should be able to adapt the Shotwell publishing system to your needs in no time.


Adding new publishing services will get easier once we have a dynamically-loadable plug-in system in Shotwell (see ticket #182), but even today it’s straightforward. If you’re interested, start by scrolling through the “Photo Publishing” section of the Architecture Overview. Once you get a feeling for the classes the make up a typical web connector and how they interact, you’re not far from subclassing them for use with your own web service.


If you do end up building your own web connector in Shotwell, by all means send us a patch. Pending a code review, we’d love to include it in the next version of Shotwell!

Hacking, Shotwell, Yorba

Bowling as a metaphor for closing tickets

1 Comment

One of the features I’m proud of in Shotwell 0.4 is our undo/redo system.  (Kudos to Rob Powell for turning me on to the Command pattern.)  Thanks to abstractions in our primary data structures, it was easy to build a set of base Command classes that deal with these generic objects in generic ways.  That’s why our undoable crop command is only 13 lines of Vala code — and that includes the class boilerplate.

When Adam first spec’d Shotwell (wa-aaa-y back in February/March of last year), he generated a slew of tickets for features he knew we wanted eventually, but in no particular order of priority.  We knew we wanted undo but didn’t know when we’d add it (or even what would be undoable).

When I first attacked the problem in November, I pointed out that coding undo does not give you redo for free.  So, Adam created a separate redo ticket in case it had to go in later.

As it turned out, I implemented Redo alongside Undo.  I was elbow-deep in the code and I could see how to get redo implemented on all the various commands, and sometimes in generic ways.  (This is why crop’s so small.)

That was pretty satisfying, closing ticket #65 and #1001 in the same commit.  Now, some of those tickets in between aren’t for Shotwell, but certainly a lot of them are.  It felt like nailing the 7-10 split in bowling.  I’m a horrible bowler, and I only remember making that shot once.  Closing two tickets separated by 936 others is likewise satisfying.

Hacking, Shotwell

If only it had been deprecated in 2001

2 Comments

You know that any post about deactivating HAL will, at some point, link to a bucket of bolts singing “Daisy Bell”, so I’ll do it now and get it over with.

The past couple of days I’ve been removing from Shotwell the deprecated (and despised!) HAL.  Shotwell’s reliance on HAL is minimal.  Most hardware interaction is through gPhoto.  What Shotwell needs is notification of devices being attached or detached (to run a gPhoto auto-detect) and a way of mapping USB ports to gPhoto camera objects (due to some legacy libusb port-naming stuff — see this and this).  udev is the preferred replacement (although there’s still some information out there saying to use DeviceKit; don’t).  Unfortunately, there’s no Vala bindings for gudev (a GObject-wrapper), so I had to build my own.

It turns out the Vala documentation for making bindings for GObject-based libraries has improved considerably, and I had a workable VAPI in just a couple of hours.  (It’s here for those interested in its state.)

gudev has a signal for when devices are added, removed, changed, etc.  That’s good.  However, it doesn’t provide a way to get subsystem-specific device information (i.e. whether a USB device is a PTP camera).  The solution was to walk the USB bus (via libusb) and match bus/device IDs with gPhoto’s auto-discovered port strings.  And that’s all there was to it.

HAL offered everything we needed (signalling and USB-specific device type information), so I can’t say I’m on the good-riddance bandwagon.  I’m not cheerleading for it either, though  Like a casual acquaintance with whom you don’t have much in common, it’s easy to say sayonara to HAL.

Hacking, Shotwell

Vala and C warnings

2 Comments

We’re frantic here at Yorba working to get Shotwell 0.4 out the door before the holidays, but I wanted to take a breather and point out a positive trend I’ve noticed with the Vala compiler.

As you may or may not know, Yorba is a 100% Vala shop — well, maybe not 100%, but the sliver of code that’s not Vala (and I’m including Make as a kind of scripting engine) is present only out of necessity.

We were sold on Vala from just about the beginning of Yorba’s existence.  One major concern was the number of C warnings gcc spat out when compiling valac’s generated source.  I’m from the medieval school of thought where Wernings Shalt Be Treatyd As Errours, but unfortunately there’s little recourse with a system like Vala.  Each warning had its own root cause.  There was no central fix that could be made to the compiler, nor was it a simple matter of rewriting the offending line.  Many warnings were due to const-correctness.

Recently I’ve noticed fewer warnings than ever.  Shotwell is approaching the 25,000-line ceiling (according to wc, blank lines stripped) and I was curious what kind of trend there’s been on warnings.  It’s positive all right:

18-Mar-2009 Vala 0.5.7: 746 lines, 4 warnings, 0.54% lines generating warnings
12-Apr-2009 Vala 0.6.1: 2,789 lines, 8 warnings, 0.29%
20-Apr-2009 Vala 0.6.1: 3,160 lines, 11 warnings, 0.35%
26-May-2009 Vala 0.7.3: 6,347 lines, 57 warnings, 0.90%
28-Jun-2009 Vala 0.7.3: 8,663 lines, 79 warnings, 0.91%
18-Sep-2009 Vala 0.7.5: 15,270 lines, 131 warnings, 0.86%
17-Dec-2009, Vala 0.7.8: 24,591 lines, 56 warnings, 0.23%

I suppose I could go crazy with the graphs, but you get the point: Shotwell’s code size is growing and the rate of warnings are dropping.  The big leap was between 0.7.5 and 0.7.8, which justifies my hunch that this was a recent development.

(I ran 18-Mar for giggles.  I don’t think a program under 1,000 lines is worth measuing in this context, but it’s fun to remember when Shotwell was just a tot.)

Zero warnings are, of course, the final goal here, but I’d say that Vala’s largest improvement of late has been its growing silence.  When you think about it, that’s what you’re really wishing for when you type “make”.