[KimDaBa] EXIF tags

[Jesper K. Pedersen]

"Cesar A. R. Crusius" <cesarcrusius at earthlink.net> writes:

| > 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).
I agree that libexif doesn't seem to be too "dangerous" to link to.

| 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.
ohh ohh, you hit me where it really hurts ;-)
I'm completely color and font blind (not technically, as in it is something
my doctor would agree on).
In other words I can't really see the diff between two fonts unless someone
explains, and similar with colors.

What I'm aiming at here is, I guess, that if the GIMP people is pushing XFree,
I'd rather let them continue on it, rather than making a fool out of my
self. Sorry.
| 
| > | 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.
You are referring to the lineedit/listbox combo where you can type in Name,
Location, and keyword, right?
I see that it doesn't show up, that indeed is a bug. 
I'll have a look soonish.
I've never needed this feature myself, for some funny reason kimdaba came
with exactly the categories I needed ;-)

| Great work, tough!
Thanks.

Thanks for the report.
Jesper.