Solang: what is brewing for 0.4
It has been a busy vacation for me and Solang. Finally we are at a point where we can release 0.4. So let me write about what we have been doing and what is new.
Integration with Tracker
The most visible change and the one which really sets Solang apart from the crowd  is that we are no longer going to use a private database for tracking photos and storing our meta-data. I had briefly written about this earlier, but let me elaborate what this really means for the user.
This means that you, as user, do not need to explicitly click some buttons and select some folders in order to import your collection of photos into Solang. Neither are the tags, that you create in Solang, going to be locked out from the rest of the desktop forcing you to start Solang everytime you need to search something based on those tags. Solang will automatically figure out where all your photos are and let you browse, tag and edit them. Later on, you can access the tags that you created and attached to your photos from other applications as well.
So what is the catch? How does this work?
We rely upon Tracker to let us know where the photos are and to keep track of all the relevant meta-data (eg., EXIF data) and tags. Tracker has a set of miners (right now it only has a filesystem miner, but things like a Flickr miner are being worked upon) which will index all your data behind the scenes. Ideally, your GNU/Linux distribution would be configuring your desktop so that Tracker is started everytime a session is initiated and everything will just work.
Thumbnailing with Tumbler
We completely overhauled our thumbnail management code. We decided to use Tumbler, which is an implementation of the thumbnail management D-Bus specification from XFCE. Other people might turn up with their own implementations but as long as they are implementing the same D-Bus API we do not care who is actually providing the functionality. To keep the application responsive under heavy loads we took a strategy similar to the one used by Thunar when dealing with the thumbnailer.
Well, we could have used GnomeDesktopThumbnailFactory too, but did not for two reasons. With the recent focus on removing libgnome(ui), and the fact that GnomeDesktopThumbnailFactory was previously part of these libraries as GnomeThumbnailFactory I was a bit skeptical about the future of this code. Moreover using Tumbler over asynchronous D-Bus calls automatically makes our application more responsive and the code simpler. GnomeDesktopThumbnailFactory does not appear to have any asynchronous functions in its API and I did not want to run a separate thread to deal with thumbnails.
Editing with GEGL
Lastly we changed our editor to work with the enlarged view itself, instead of having its own view. This should smoothen the workflow for the users as they will not have to move to a different view just to rotate or reflect the odd photo while looking at a collection in enlarged mode.
Secondly, we are going to rely as much as possible on GEGL for our image manipulation code. Previously there were some concerns because GEGL was really really slow, even for some basic operations like rotating by a multiple of 90 degrees or reflections aligned to the axes. However there has been some improvements regarding these issues recently, and using GEGL will make it much more easy for us to add support for higher bit depths and RAW processing later on. After all I want to focus on doing it right instead of doing it quick.
 We still want to remain as light as possible.