[Kde-imaging] gwenview, digikam, keywords and metadata

[Kristian Rink]

Am Mittwoch, 5. Dezember 2012, 15:53:58 schrieb Aurélien Gâteau:
[...]
> > Iptc.Application2.Keywords to be used for such information (AFAICT digikam
> > uses to write these to at least three or four different IPTC / EXIF tags).
> > But ultimately, it works, and it does write things found in Nepomuk back
> > to the image. I'll try pushing this to my github repo and spend some more
> > work on it sooner or later to make it more useful.
> 
> That's a good start, I would vote for it to work recursively on a folder.
>

Yeah. Thought about that, too; so far just using it through "find" which seemed 
the most straightforward way to do things without having to deal with 
implementing file system traversal. Should be doable, though. :)  At the 
moment, actually, I'm playing a bit with the various kinds of metadata 
supported by EXIF headers and written by digikam (including EXIF, IPTC and 
XMP) to see which provide "best" results with external third-party 
applications. 

> I also wonder if it would be possible to ask Nepomuk which files had
> metadata changes since a given date. If you have this information it is
> possible to implement an incremental syncing. You may want to get in touch
> with the Nepomuk developers to know if this is possible.

Hmmm, yes, this sounds reasonable. I'll see whether this is possible about 
that. Best would possibly be having some way to hook into Nepomuk Storage 
Service, triggering some external actions after(?) image metadata has been 
stored... Possibly this would be even cleaner than forcing applications such 
as gwenview to take care of such modifications itself.


[...]
> > stored in there in case any of the image files gets copied or moved, at
> > worst while Nepomuk/KDE is not running (Unix shell, some other desktop
> > environment, ...)? This seems like just begging for inconsistency. But
> > possibly this is a bit off-topic here. :)
> 
> Another good question for the Nepomuk developers :)

I will try. Generally, this seems sort of a difficult issue, possibly only to be 
resolved by running a service such as Nepomuk directly during system startup. 
Though Nepomuk seems to come with a File Watcher service which is capable (to 
some degree?) of handling file system changes, it possibly won't handle changes 
done to files using the unix shell while Nepomuk services are offline... ;)

Cheers,
Kristian