S K Ä R V A

Making Photos From Scratch

No this does not have to do with film or cameras. At least not film, and not direcly with cameras. Let me explain.

Focus Pull

My operating system of choice is elementaryOS and I try to contribute to it as much as I can, usually in the form of code reviews and testing. I got my start with writing bug fixes and try to do that still if it seems like an interesting problem or I feel confident that I have capacity to follow through. One aspect of elementary in particular is lacking an advocate or core developer that I think has a lot of potential, and I would like to use more regularly; Photos. The current version is an old fork of an old application called Shotwell, whose original developers moved on over a decade ago, is written for GTK3 with a lot of classes whose functions are now taken care of in some library under the GTK umbrella, and has no support for newer compression formats like AVIF. Between all of that and stability that is not guaranteed with large image libraries, it is in big need of updating. I like a lot what is there, I don’t do heavy editing of my photos so a simple UI and feature set like it has makes me happy, but there are plenty of things about the app I find frustrating and bad that are either easy changes or related to code age and stability. After some discussions over the years and getting involved with the codebase, the path forward for Photos is narrowed to 3 options:

  1. Simply archive and get rid of the app. Let users download and use something else
  2. Take the existing codebase, and port it to GTK4 and do some obvious cleanup or feature removal
  3. Start over and rewrite the entire app from the ground up, making use of newer libraries and tech

My personal opinion was to simply toss it and start over. This is coming from jumping into the code to understand how it did some things and even attempting to address bug reports or feature requests. The code is quite old and over-complicated at this point. Dani said if I want to take that on she would be happy to not have to worry about the app. So I started digging into GTK4 and what kind of libraries exist now for Vala that could make all of this way easier, and keeping thoughts of how it could be redesigned in the back of my mind. The first huge hurdle was the library monitoring.

From Camera Roll to App Scroll

Lots of places for photos to end up after they are pulled off of the camera Starting off I am going to look only in the Pictures directory until I figure out best way to handle monitoring Looked into existing solutions which ended up with two options: Making something similar to the existing monitor (essentially porting it) or make use of LocalSearch, a daemon that does indexing of the filesystem and keeps this data in an RDF triple store that is interfaced with via TSparql. I have no experience with LocalSearch and have no idea what a triplestore is or what its ontologies are. That said, it is supposed to be low-memory and very fast, and looking at what existed already in Photos what huge and clunky and reimplementing what LocalSearch was doing but not threaded and memory hungry. After a bit of chat with Jeremy and Dani about the situation, it was concluded that I should take a look at LocalSearch and TSparql so I did.

Getting my head around how it all works took me days, particularly the subject-predicate-object query syntax to get the information I wanted, but I did eventually get a very basic Gtk/Granite application foundation that would connect to LocalSearch and grab the file path for the 9000+ photos I have sitting in my Pictures folder. The query looked like this:

SELECT ?path { GRAPH tracker:Pictures { ?photoObj a nmm:Photo ; nie:isStoredAs ?path . FILTER(contains(?path, 'Pictures')) }}

Pretty short line, but it gets all of the photos that exist in my Pictures directory, and it does seem to do it very fast. Without doing any kind of optimizing with the query or threading with GTK the app will open, connect to TSparql, query, pull the path data into the app’s model, and create the scrolling window with widgets that show the path in a couple of seconds. Compared to something like Lightroom that is a pretty fast launch time. Granted it will slow down some as the widgets get a little more complex from grabbing thumbnails and whatnot, but grabbing data in a separate thread will go a long way to make the UI feel very snappy and responsive while it does this.

Next Steps

To me going with this solution seems very promising but I need to go a little further with the experiment to feel comfortable going to Dani and suggesting that we start shipping elementaryOS with LocalSearch installed and relying on it for Photos. Next steps will be doing some basic threading with the UI so it can run uninterrupted, and adding a photo view to navigate to from the grid view that will actually display the photo with some additional data (maybe exif, maybe just stick with the bit of data already in LocalSearch) so that way it is a somewhat “complete” experience to look over a library and look at cool photos! :)