[KPhotoAlbum] General interfacing (was Re: Configuration dialog RFE/annoyance)

[Robert L Krawitz]

   Date: Sat, 4 Mar 2006 16:18:53 -0500
   From: "Mark Eichin" <eichin at gmail.com>

   On 3/4/06, Robert L Krawitz <rlk at alum.mit.edu> wrote:
   > I have yet to find a better tool for organizing photographs.  My
   > wife uses iPhoto, which is dreadfully slow and doesn't really
   > seem to offer much of anything that KPhotoAlbum doesn't.
   > KPhotoAlbum is blazingly fast; much of it seems to be limited by
   > disk/filesystem performance more than anything else.

   Indeed, I've tried to use iphoto a number of times - and usually
   with each new major release, I find that it just can't handle my
   collection size.  (Even if it could, I probably wouldn't *like* it
   because it's not very keyboard-friendly - I run kimdaba under
   ratpoison, and so far I have 3000 photos in it and it just cooks
   along...)

I'm at around 11,000 photos right now.  We've had a lot of discussion
on the list here about the importance of scaling to 50,000 or more.
Every now and then I try playing around with f-spot or digikam or
whatnot, and I never find it very satisfactory.

   > One thing that would be handy (and probably very simple) would be to
   > integrate it with PhotoPrint.  That's a Gutenprint client that one of
   > our developers has put together (see
   > http://www.blackfiveservices.co.uk/PhotoPrint/About.shtml).  Currently
   > I have to export photographs to a directory and then run PhotoPrint;
   > it would be very neat to have some kind of integration.

   While gutenprint should probably get directly integrated (is
   gutenprint isolated enough that the fact that one is GTK and the other
   is KDE likely to not matter?)  it occurs to me that I should elaborate
   on the strategy I used for flickr-sync, even if it isn't quite ready
   for primetime:
   http://www.thok.org/intranet/python/exif/index.html

(Copying Alastair Robinson, the PhotoPrint author)

Gutenprint itself is just a library of printer drivers, albeit with an
API that permits building user interfaces around it.  PhotoPrint is
based on GTK+, but it's possible to pass in a list of images via the
command line.

   The key discovery is that (1) python cElementTree is well-suited to
   the flavor of XML kimdaba uses, and is very fast (2) "I want to do
   this" is a valid meaning for a tag, beyond the usual "this is in
   this picture" or "this picture is about this".

   If I'm reviewing pictures and decide I want to put one up on
   flickr, I just add "flickr" as a tag.  After saving/exiting
   kimdaba, I run the tool, which parses the XML, finds all pictures
   tagged with flickr, and uploads them.  Once the upload works, it
   adds *another* tag to the picture, "flickd"; next time around it
   filters those out when looking for things to upload.  [An alternate
   strategy would be to delete the "flickr" tag but I happen to like
   knowing which pictures I've already uploaded.]  While uploading, it
   includes all of the other tags as well.

   This strategy could be used for other programs; you could drill
   down to a subset, use c-2 to mass-tag them, and then run the
   standalone tool.  Alternatively, you could set up "standing orders"
   - for example, I take a lot of pictures for work, including
   pictures of whiteboards for-the-record; by tagging those with work
   + whiteboard, currently I can manually select them and generate an
   album, but ultimately I want to have an automatic tool do that.  (I
   haven't found a Kimdaba "batch mode" or I'd have already done it -
   instead I'll probably end up using kid templates for an album
   builder...  Back in the day, I did this with some perl scripts and
   BINS (sautret.org) but it had scaling issues too...)

   This does rely on the index.xml format not changing much, but if it
   stores the same data it probably isn't going to ever end up *too*
   different.