[KimDaBa] Next release one week, then what?!
jedd at progsoc.org
Tue Apr 26 11:36:44 BST 2005
On Tue April 26 2005 05:57 pm, Vincent Picavet wrote:
] 0) Up to date debian packages in the sid official repository, with
] kipi-plugin support.
Just in case you don't know about them, they're maintained
here for now. (It'll also help people searching for this in the
archives.) Needless to say this isn't something that Jesper can
do much about.
# unoffocial kimdaba packages
deb http://www.mpe.mpg.de/~ach/debian/experimental ./
] 3) Speed : with more than 8000 images, kimdaba is not as quick as I
] would like it to be. One direction for this would be (as already said
] by someone else) to separate the storage of data from the rest, enabling
] to use a database or something else than a single xml file.
This was discussed in great depth a while back, and the conclusions
(if memory serves) included that the .xml file wasn't the problem.
It's a very small file - in my case 2.7mb for about 10,000 images,
and the load & parse time was a very small part of the start-up
delay, and certainly not a problem for the run-time performance.
A database would certainly solve other problems, though - such as
concurrent access. It would probably not do much as far as the
synchronisation issue between different instances, though.
] Another quick and simple thing would be to be able to load separate
] databases. I therefore have two or three batches of photos which have
Yeah, I've been thinking about this requirement too. I have a
bunch of photos that aren't about *me* (and my friends), but I
still would like a nice way of indexing them, keeping them separate
from the main archive. It's easily scriptable, but there's opportunity
there to make it better handled natively.
Web gallery stuff - at the moment I can't see an elegant way of
sync'ing my pictures to the web, since it's such a manual process
for my gallery - I like to use imagemagick to put the raised border
around them, make a thumbnail that's as small as possible but
still useful, and ditto with the 'main' picture (usually getting it
between 100 and 500 mb, with manual iterations of ImageMagick's
excellent convert utility). I imagine that any automated photo
gallery post-to-a-web-page thing would be severely limited once
you started to use it much, and you'd end up doing lots of things
manually anyway. (I may be wrong - I accept that I've got a very
particular way of doing things.)
] 6) Predefined filtering, or "dynamic selection" : let the user define
] a selection and display it. This gives the advantage of not having to
] manually having to set a given keyword to the new images corresponding
] to this selection.
Ahh, yeah .. 'previous searches' or the virtual folders we're seeing
in lots of mail clients now.
Nice idea. Not sure how often it'd be used, but if it pops up in
a collapsible tree view thing in the main window, it wouldn't take
up much space when it wasn't being used.
More information about the Kphotoalbum