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

[Eivind]

On Saturday 23 April 2005 17:44, Jesper K. Pedersen wrote:

>              A N D   T H E N     W H A T ???

1) Exif. 
--------

1a) At a *minimum* some way to "View Exif info" when displaying an image. 
It's all fine and good to add and use more meta-info about an image, but 
we should atleast be able to use the meta-info that is already there.

1b) Better yet: Make it possibe to add new Categories, and indicate that 
they should be auto-filled from exif-field so and so. (So I could make a 
new Category "Cameras", and indicate that it should be auto-filled from 
the Exif-field "Camera-Model"

1c) Even more flexible alternative: Make it possible to add new Categories 
which initial value is the output of a freely choosable shell-command. 
That way I could create "Cameras" and indicate that the initial value 
should be the output of the command:

jhead %image | grep "Camera model" | cut -d: -f2

Yes, this is only really useful for power-users, but it gives 
extraordinarily flexibility. I can have Kimdaba automatically recognize 
*any* aspect of an image for which I am capable of writing a shell-script.

2) Time
-------

Be more flexible in the use of time-information. Make it possible for me to 
search for images that are taken between 18 and 24 in the evening. Or make 
it possible to search for images taken in the weekend. Yes, I realize this 
is more tricky than simply restricting to a range as is possible now.

3) Database
-----------

3a) Decouple Kimdaba from the storage of the data. Thus making it possible 
to use different backends. For example, some migth wish to use a 
SQL-database as backend, which would make it possible for multiple users 
to use a single kimdaba-database read-write simultaneously.

3b) I *think* kimdaba currently loads all info on startup, and saves all on 
exit. This is probably a scalability-problem at some point, and besides it 
plays badly with i.e. SQL. Better would be for the frontend to always 
query the backend when it needs data. Some backends could then have all 
data in RAM and return it from there, others could get the data on demand, 
f.ex from a database and return it.

4) Metadata.
------------

Make it possible to associate any file with one or more images. Many 
digicams can record sound. Why can't I use that to record comments to 
images, and then somehow indicate that tierpark_comments.mp3 is associated 
with images DCP_0375 - DCP_0415 ?

5) Multiple formats.
--------------------

Make it possible to indicate that multiple image-files represent the "same" 
image. I might have XXX.raw, XXX.jpg and XXX_scaled_down.jpg They're all 
the same image though, which means they're taken with the same camera, in 
the same location, containing the same persons etc. It also probably means 
I only need to be shown one of them when I search. (possible with some 
indication overlayed that multiple versions exist)

And last, but not in any way least: *Don't change the name*.

There's *WAAAAAY* to many name-changes. It only confuses people. The name 
is only a label. People have no chance of associating anything with the 
label if it changes all the time. The name doesn't need to mean anything. 
Certainly not something the users understand. People think of "gimp", not 
of the "Gnu Image Manipulation Program". If you ask people what "gimp" is, 
you get a lot of correct answer. If you ask people if they ever heard of 
the "Gnu Image Manipulation Program", less people will associate anything.

If too few people know Kimdaba, work on changing that. Changing the name 
will only ensure that we have a name that *zero* people associate anything 
with instead of a name that "too few" people associate anything with.


	Eivind Kjørstad