[KimDaBa] Next release one week, then what?!

[jedd]

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.

 Jedd.