[KimDaBa] LWN & Grand Plans
jedd
jedd at progsoc.org
Sun Apr 24 14:34:04 BST 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 Kphotoalbum
mailing list