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

[Jesper K. Pedersen]

On Monday 25 April 2005 07:57, Eivind wrote:
| 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.
Two nice suggestion, but it would really not get us much further would it, I 
mean we would still not be able to search for shutter time between 1/300 and 
1/500.

| 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.
Would that be something that is really usefull?

| 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.
More on this in another thread.

| 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 ?
Sounds like a good idea, though it would require some way of invoking the 
external media file. I'll think about it.

| 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)
Hmmm, I understand, the problem is, however, (1) I wouldn't use it myself, 
risking it to me a buggy feature (2) I doubt anyone not having a camera with 
RAW files would ever use this.

| 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.
I installed a new Suse just yesterday, and I found kimdaba in the installer, 
it was not installed by default. How would I know that kimdaba was this cool 
application to use, thats why we need a more descriptive name, perhaps even 
chaning to KImageDatabase would solve things, I dont know.