I have a UITapGestureRecognizer linked up to an IBAction. I am simply trying to confirm the IBAction method call. For the UITapGestureRecognizer, in storyboard I have a reference outlet collection to gestureRecognizers in my View and sent action tapGesture: linked up to my ViewController.

.h code:

- (IBAction)tapGesture:(UITapGestureRecognizer *)sender;


.m code:

- (IBAction)tapGesture:(UITapGestureRecognizer *)sender {
     NSLog(@"Tapped");
}


What am I missing? Why is tapGesture: not firing?




Question: Bulk exporting/archiving collections in Lightroom
Answer: I'm not sure exactly what you mean by "mimics their collections," but I do something similar to what you're describing in my Dropbox and Aperture exports.

(Dropbox for off-site backup, Aperture for intelligent iDevice sharing. Yes, I bought Aperture just to make iTunes happy. You're welcome, Apple.)

I use Jeffrey Friedl's Folder Publisher plugin, rather than the Collection Publisher. I chose it because what I'm interested in is mirroring the on-disk folder structure as represented in LR's Folders pane, but using Smart Collections to select which photos get published.

Like you, I choose not to mirror my low-rated photos to the export sets, for example, a perfect job for Smart Collections.

If you use the built-in Hard Drive publish service instead, you get a flat folder of images, with name collisions resolved rather brutally.

For some reason, photo names don't always survive a trip through the Folder Publisher intact. If I have a 1.jpg in two different folders, they seem to get a unique number appended anyway, even though it isn't actually necessary. I suspect this is a limitation of the Lightroom programming API. There are a lot of such areas, where the limits of Adobe's own needs for the API get reflected into the API, so that Adobe's limitations become your limitations.

That problem doesn't really bother me, though, since the name of a photo file is of minimal concern. If I ever had to rebuild my Lightroom library from a Dropbox snapshot (shudder) I'd be much more interested in the folder structure and the photo metadata, both of which the Folder Publisher plugin preserves.

About the only metadata you lose are things like virtual copies and stacks.

Obviously you're also baking photo adjustments (DNG + XMP) into JPEGs when doing this. You should have a separate "real" backup.

I consider my Dropbox export to be a "my house burned down and then my city was hit by an asteroid and then it slid into an abyss" sort of backup. As for the Aperture export, photo names, the distinction between multiple JPEGs and virtual copies, and stacking is of no concern whatsoever.

Another option you can look into is LR/TreeExporter. I used to use it, but it hasn't been updated since the LR3 days, and at the time I started using it, the jf Folder Publisher plugin hadn't been created yet. Jeffrey is more responsive, and I like the way the plugin works better besides.