[KimDaBa] EXIF tags

[Cesar A. R. Crusius]

> Well if you could supply me with code for reading EXIF data, then we are a
> long way, the rest I could easily handle.
>
> My greatest concern about all this EXIF stuff is to rely on 3rd party
> libraries. You have no idea how many people ask me how to compile kimdaba
> on system XXX. If an extra dependency to some third party library is added,
> then I'd have to mess with configure files for ever, plus do support to
> people to whom this configure test fails.
> So if you look into this, please try to see if you can use, whatever,
> functionality already is in kde-graphics (still 3rd party to kimdaba, but
> not as 3rd party as some foo.lib only partly supported...)

You'll need an extra dependency, on libexif. I don't think that's a big 
problem tough, as 'kdegraphics' depends on it (at least on FreeBSD), as do 
gphoto, gimp, and sane-backends. If you deal with pictures, you can assume 
it's there (all those also depend on the jpeg libraries, for example).

For a KDE example where EXIF is dealt with you should probably look at 
PixiePlus, a KDE image browser that I used before switching to KimDaBa. (I 
think it uses ImageMagick libraries tough.)

It is possible that some KDE things already require libexif (as hinted by the 
kdegraphics dependency), so you are probably not introducing any new 
requirements anyway. I don't think Qt does, otherwise it would be a 
dependency on Qt itself.

This falls on the same category as color management. I don't know if the 
libraries KimDaBa uses already take care of that (I think not), but when 
displaying images one should render them correctly if they come with a color 
profile. The standard library to use for that is 'lcms'. Strictly speaking, 
this should be a part of the underlying system, in this case either Linux or 
KDE/Qt/X. I think X is the right place but I don't understand their 
development model. But as the author of a graphics program I think you should 
make the point to those communities, it is a problem that plagues all non-Mac 
platforms and is relatively easy to solve (it's a constant topic on, for 
example, the gimp lists, and they're trying to solve it in gimp itself). 
"Fixing" it on every single application that needs CM (read any image 
manipulation program) is kind of stupid. A KDE program that uses color 
management already is 'Scribus', based on lcms.

> | Another feature I'd like to add is the ability to change thumbnail size
> | on the fly, with a pulldown box in the menubar.  Any comments on this
> | one?

Since we're talking about new features, one basic one I miss a lot is the 
ability for KimDaBa to remember the dialog settings for the next sessions. 
For example, I have a 'Film' field that I use for my pictures, but I have to 
explicitly make it show up on the dialog every time I start KimDaBa. This 
type of info (GUI settings) probably belong in a .kimbadarc file, not in the 
database itself, tough.

Great work, tough!

-- 
Cesar A. R. Crusius
Synthesis Architect, Barcelona Design Inc.
The OPS convex optimization system (http://ops.sourceforge.net)