[KimDaBa] Next release one week, then what?!
ekj at zet.no
Mon Apr 25 08:57:50 CEST 2005
On Saturday 23 April 2005 17:44, Jesper K. Pedersen wrote:
> A N D T H E N W H A T ???
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.
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.
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.
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.
More information about the KimDaBa