Dave Neary wrote:
>>> You cannot use this plug-in to work with EXIF data, unfortunately: it
>>> is stored in a binary format that requires special handling.
>>
>> Any plans to add this in the future?
>
> There have been (long) discussions on this before...
>
> [ . . . ]
>
> Somewhere in there you might find some ideas for how exif data
> could be handled :)
Actually it's not so hard. The libexif site contains code for a
widget called "gtk_exif_browser", which operates on an exif_data
structure of the sort that you (Dave) wrote the code to load from
a jpeg file for people who have libexif. So it's simply a matter
of writing a plug-in that starts a gtk_exif_browser and feeds the
contents of the jpeg-exif-data parasite to it -- really not
more than a few hours of work, probably. The only downside is
that the gtk_exif_browser code is unmaintained and rather buggy,
but it does at least basically work. (The libexif site also
has the code for a program called gexif which is simply a wrapper
around gtk_exif_browser. All of this stuff compiles straightforwardly
except that you have to turn off -DGTK_DISABLE_DEPRECATED in the
Makefile.)
> Personally I think it would be easier to have an EXIF editor, a
> Dublin Core editor, an IPTC/XMP editor and so on, rather than have
> one generic one size fits all metadata editor which magically makes
> itself look OK regardless of the data involved.
I agree completely, at least for the initial stages of development.
At some point in the future, it might be desirable to try to
wrap things up neatly -- but not now.
Best,
-- Bill
______________ ______________ ______________ ______________
Sent via the KillerWebMail system at primate.ucdavis.edu
