GNOME Photos final landing with Google Photos- 4 mins
Things are now a bit awesome and stable
Well, that doesn’t go hand in hand, right? Things are awesome but they are not stable initially. GNOME Photos faced things no differently. While we had landed patches for Google Photos sharing earlier this summer,it took time to get stable and handling those shared images. It’s not only about the sharing but all the things around it.
Big changes were on the way!
The item manager - gut of the application. We have changed item-manager from single hash table holding all the items (items can be a single local/remote/favorite image or a collection album as a whole) to child hash tables. I think this is the biggest change at the backend and landing this major change required testing to keep things consistent at the front end.
Item manager used to hold “all” items as mentioned earlier. According to the mode changed (mode can be SEARCH MODE, OVERVIEW MODE, COLLECTION MODE etc.), queries were generated by the query builder engine which returned the items according to the mode chosen by the user. This was the rework (filtering again) from a pool of all images the application has to do for the user.
From now on:
Now, there is no need of second filtering. We have “disintegrated” the pool into small child hash tables. Each mode has its own specific hash table and item manager is nothing but the collection of these smaller hash tables. The view model will just mirror the items present in its own mode-specific hashtable.
This will help us to migrate easily to the GtkFlowBox like below.
If you have not read my earlier posts, I will try to summarize about the duplication problem. GNOME Photos already has various online miners (gnome online miners for Facebook, Google, Flickr, etc.). If you upload one of your image to these share locations from the application itself, finally you’ll end up with the original image (which is shared) and the remote image which will be fetched by the online miner. Also, the image can be shared to multiple share locations which can duplicate a single image, multiple times.
The problem can be solved if there is some kind of mapping between the original image and the remote image. This mapping can be provided by the tracker in the form of “nie:relatedTo” and “nie:links”. Thus, doing some intelligent work with the view model based on this mapping, we can solve the duplication issue.
Changes in gnome-online-miners
Earlier I wrote the code to provide mapping between original and shared images.However, we found that much of the code can be shared with gnome-online-miners. Before mapping, it is worth to mention that we were also inserting a remote object into the tracker’s database with the same identifier manually. Why manually? To get the URN of remote object. Gnome-online-miners does a similar thing but we cannot get back the URN of remote object that is needed to map it with the local image.
Therefore, Debarshi wrote a GDbus method to return the URN of remote object inserted by gnome-online-miners. Check out git logs on master of gnome-online-miners.
What if you lose the tracker’s database or the image is transferred to another computer which is running gnome-photos?
Well, this takes the problem to the next level. Only local mapping between the original image and the remote object will not do the job. The “shared” information should go with the image whereever it is transferred. There, image metadata XMP comes into play. Along with the mapping we do with the help of tracker we also embed XMP metadata (commit) into the image with the help of GExiv2.
Are we done solving the issue?
Not yet.We still need to read the XMP metadata whenever the image is transferred and create same tracker’s relations in its database. Same in sense, the relations which existed on the original machines’s tracker database. Therefore, this part is still remaining and will be addressed for the 3.24 release.
Although my GSoC’s project was regarding only “Uploading Photos to Google”, I will still be working on share-point-manager to extend share-points to Facebook, Flickr etc. Mutiple uploads and export of images will also be the area I’ll be looking into along with the “album” sharing to Google. I don’t know what else I’ll be working on in photos but the decision will be of my mentor’s Debarshi, as he knows what would be good or bad for me. :) There is still a lot left to learn from him (read as: I will continue bugging him :P). I hope he would not mind that!
Stay tuned. Happy Hacking.