Here: http://gitorious.org/gexiv2

Having investigated this (and getting very far at it), we made the call not to continue in that direction, in particular because we weren’t very happy with the API.

As a side-benefit, doing this in fully managed C# code means we get free portability, something that is quite often an issue too with C/C++ (despite the fact that they are generally claimed to be “portable”).

http://dev.exiv2.org/boards/3/topics/show/162

Adobe XMP Toolkit
Exempi
Exiv2
Exiftool

are not enough, and because adding complete and correct support for Exif, IPTC, XMP and every camera makenotes is such an easy task.

Reinventing the wheel, NIH and such come to mind…

This coming from someone who works with C all day, and loves the low-level feeling of the language.

Has the option of putting all this into tracker been considered before and discarded? The f-spot work rubenv did for SoC enables reproducible image transformation workflows. Imagine this use case if that workflow is inside tracker and managed across applications:

- I take a photograph in RAW, convert it to a JPG, resize and crop it, alter its colors to be a funky red and white monochromatic, include it in a LaTeX file together with some formatted text, generate a PDF file from it and finally use a desktop publishing app to turn it into a fold-out brochure with three more pieces of text.
- I later decide to change the funky red and white monochromatic to blue and white. Since the transformation steps are included inside tracker and there is an orchestration piece of software that knows that files have changed and it should regenerate the chain I get a nice dialog that says “You’ve performed a change in an image that is used in this other file, do you want to update the file? (Continue, Break Link, Cancel)”

This is basically bringing the power of Make/Unix pipes to the GUI. You could even have an “export to Make” function where you package a set of files as a makefile and can import the set in another machine with the connections intact.

Even without this orchestration functionality having all the metadata inside tracker would free the data that is currently application specific. If enough standardization is done things like banshee and f-spot could be split up into modules. I can see f-spot not being a monolithic application and instead be:

- A plugin for nautilus to view the photos on the disk indexed by its metadata (tags, rolls, dates, etc)
- A set of exporters to send photos to flickr/facebook/etc
- An importer to get photos from media, catalog them as the user wants it (give it tags, assign rolls/events, etc)
- A set of converters that take an image in the broad sense (its RAW+JPEG+conversions+metadata+orchestration between versions) and operate on it generating more images, metadata and orchestration information

You could still package all of these together at the UI level as a single application if you want to give users an Aperture-style interaction. But what you could also do is stuff like:

- Import all the audio recordings, videos and photos from a specific event at the same time since they are on the same SD card. Catalog them together.
- Export video/audio/photos to facebook together with descriptions
- Search and catalog all of these plus text files and others all through the same interface in nautilus with a consistent set of tags

Getting all of these use cases working would take a bunch of coding but the point is that the data is the important bit. If we have a centralized and formalized way to describe what all the files are, anyone can write an application to enable one specific use case without having to hack into f-spot/banshee at all and in whatever language he wants to do it in.

Just my overly verbose 2 cents. I’m not assuming I am right at all and would love to hear others’ opinions.

don’t get me wrong: I have nothing against mono and I actually think that C# is a reasonable choice for applications like Banshee and F-Spot. But I still do think it is a shame when the libraries doing the very basic functionalities aren’t shared as much as possible between applications. Sadly, C seems to be the lowest common denominator, which makes it the best choice _if_ you want to share your work.

Søren, It may surprise you but being written for .NET, TagLib# was able to gain a much larger user base than C, C++, and Python libraries written to accomplish similar goals. The big problem with C libaries is that they aren’t as portable as you would think and they rarely bridge the Linux and Windows worlds. Because .NET has a significant number of users and compiled Mono libraries run on Windows, I am still contacted to this day by people who want to integrate it with their commercial/shareware/freeware applications.

I love C as much as the next guy but you have got to take it off of its pedestal.

“Furthermore, should Banshee ever decide to add photo support. it’ll be ready for them to use.”

To create the Netscape Navigator of media applications? Please no. :-) I love Banshee and F-Spot, but their uses are so vastly different I can’t imagine why you’d integrate them. Maybe you guys can pull it off, but I’m wary of monolithic apps like OpenOffice, Eclipse, SeaMonkey, etc.

@Søren Hauberg
Other C# apps can re-use the code. Do you troll every Python library asking them to rewrite in plain C as well? People should use whatever language they please! :-)

@anonymous coward:
I’m guessing yes. C++ isn’t very popular in the Gnome world, and Python’s performance in non-trivial desktop applications is…less than desirable. :-) The anti-Mono crowd just seems to be a lot more vocal than say: the anti-C++ crowd. Probably due to having a high profile figurehead like RMS involved.

Full disclosure: I’m a Python web developer as well as a happy Banshee, F-Spot, and Tomboy user.