[KimDaBa] LWN & Grand Plans

jedd jedd at progsoc.org
Mon Apr 25 00:34:04 CEST 2005


On Fri April 22 2005 07:05 pm, Jesper K. Pedersen wrote:
 ] A coworker of mine sent me an article from LWN 
 ] (The Grumpy Editor's Guide to Image Management Applications)

 Sadly this is only available by subscription at the moment, and
 won't be 'free' until the 28th.

 But it's often the case with reviews - while looking for this article
 on the lwn.net site I found the same reviewer's article about various
 email clients.  Some untruths mixed up with subjective assessment,
 wrapped up in a non-standard set of criteria between each of the
 products being reviewed.  Writing a comparative review is very
 difficult, and obviously exceeds the skill-set of most people out
 there who like to crap on about GNU/Linux stuff for a living.

 I've said it before, but KimDaBa and amaroK have this in common.
 They're both really good at what they do, but they don't try and do
 their thing in the traditional way.  This is their strength (they
 work much better than the limited designs of previous attempts)
 and in a way their weakness (they require a mental shift by their
 users, and that mental shift is often beyond the capabilities of
 someone who's trying to install, test, and write a few paragraphs
 about it in under an hour).

 I'll read the article in a few days, I guess.  Hopefully they'll give
 you (Jesper) the right of reply.


 As to Grand Plans ..

 I echo the EXIF stuff.  One of the reasons I use gqview frequently
 is to use its (ctrl-e ! :) EXIF display function while browsing through
 photos.  Probably not a hugely demanded feature, but given I use
 it for checking out the differences in aperture / shutter / etc on
 similar photos, as part of my 'learning to be a photographer' thing,
 and the growing number of digital-camera inspired would-be
 photographers out there .. I expect this feature will become more
 desired amongst KimDaBa's user base.

 So, displaying (selected bits) of the EXIF data while browsing photos
 (as well as in hover pop-ups) - yes please.

 Searching on EXIF data - also would be very handy (I don't think
 I've had a need for this feature yet, but it's probably because I
 know that I can't do it, short of a lengthy one-liner bash script).

 Pulling in meta data from the image's location in the file system
 would be pretty useful, too, but have no ideas on how I'd want to
 be able to use that data.  Obviously it'd need to be massaged slightly
 (I don't want all my photos getting the keywords 'home' and 'jedd'
 for instance :)

 I think red-eye (etc) is best left to the kipi plugins - in part
 because they already cover this feature, and in part because it goes
 against KimDaBa's set-in-stone policy of never, ever, modifying the
 images themselves.

 Having concurrent access to the .xml file would be neat - and this
 of course probably implies a db back-end - which is something that,
 from memory, was discussed about 8 months ago.  I think it was
 decided then that flat file loading wasn't a problem, but at some
 point in the future the average user's photo collection might get
 large enough to make a DB the logical storage medium.  But for
 concurrent access, it becomes nearly essential.  I don't like DB's
 because it's more complicated for me to sync my image sub-dir
 and KimDaBa data (by which I mean index.xml) between my laptop
 and my desktop.  Some nice way of import/exporting the data, and
 having some kind of journal that logs when changes were made to the
 various data, kind of leads into the next idea .. 

 .. a neater way of two people updating the KimDaBa DB (in whatever
 form it takes - xml, sql, txt ;) on different machines, and then
 having both sets of changes being merged for both people (ie, two way)
 including coping with the addition of new files to the 'tree'.  The
 new image file bit is something best left to rsync (f.e.) and up to
 the user to manage, but certainly some way of letting the three
 people who have access to our image collection all being able to make
 changes (corrections, additions) and having those changes propagated
 to the other two people .. well, yeah, you get the idea.

 Jedd.



More information about the KimDaBa mailing list