This is the January 2023 update.

We start the year by a Rust implementation of the file import. It landed very early as the final stretch of work in 2022.

Then a lot of cleanups, removing no longer needed cxx bindings and no longer used C++ code. This also allow removing some "wrapper" type used in the Rust code base.

The other gphoto2-rs patch has also been merged.

Import work

Fixed some bugs ported over, like improper logic for the camera import: properly use the storage. It was just a matter of properly using the API.

Also I'm working on improving (finishing) the whole import workflow, as I want to be able to automatically sort image into folder by date, I started adding support for getting the date from files being imported. Some of the work in progress led to more patches:

• gphoto-rs: the need to be able to get the EXIF data (pr#53, merged). This API wasn't available.
• rexiv2: the need to load EXIF data from the APP1 segment (pr#62, merge) of a JPEG, which is what libgphoto2 returns when getting the EXIF data. This led to a patch for gexiv2-sys (pr#21, merged) to first implement this binding. And also a bug fix for a divide by 0 panic (pr#61, merged).
• gphoto2: and then I realized the command line for gphoto2 didn't offer the functionality either. This has been addressed too (pr#559, merged), albeit it was totally unecessary here, except as test tooling.

All in all, fixing the stack distract from the core work, but it has to be done, and everybody wins.

I also wrote code to support automatically sorting files into folders based on the date. It will be about connecting the dots and making a UI for it.

Previews

I started looking at generalizing the thumbnailing, to become previewing. In the end it's the same thing with different processing parameters and size. And then caching all of that. Here are a few ideas:

• back the cache with a sqlite3 database. (it needs to be persistant, but I don't think it should be part of the main database for the catalog)
• establish a mechanism to invalidate the cache based on processing parameters.
• make the fetch process take note of the last access.
• finally make this totally asynchronous.

This is just conceptual as I write this. The idea is that if we ever rendered that image, we'll get it from cache the next time. Currently we do that for the thumbnails that are extracted from the EXIF, but the cache is very primitive, not cleaned up, and doesn't handle the fact that we'd want the processed image. Mind you we only have some primitive rendering of the raw image..

This leads to cleaning up the a bit the current thumbnail cache. I removed some old code that implemented the queue to just use mpsc channels from the Rust library, and added rayon to trigger the renders in parallel. It doesn't seem to make a huge difference with the thumbnailing (libopenraw extract the thumbnail from the fast and it relatively fast), but it should be better when we start rendering the whole image.

i18n

I also added my new macro crate for gettext format, i18n-format.

Build

I added the "Development" profile, which cause the development version to use a different config. The only goal here is to be able to use development snapshots independently from the development code, i.e. not risking opening a good catalog with broken development code as the database schema will evolve over time.

Cleanup

I also took a pass at removing a lot of the cxx bindings related to the import code as they are no longer necessary. Less is more.

This feels like I wrote that code for nothing, but my permanent objective on rewritting to Rust is to not lose features or introduce bugs. So the bindings were a necessary scaffolding, and I didn't really know for how long.

I also removed more old bits of C++ code that never got used, which allowed me to remove another set of bindings and will help porting more of the UI code, possibling inverting the language stack and finally having the entry point in Rust, ie. Rust will link to the C++ code instead of the other way.

Side projects

While porting libopenraw to Rust, I have implemented a small GUI app to render files for debugging. It's written with Relm, and trying to make it more usefull, I had to learn how to make component. I had to fix the documentation that was still on the older API.

This led me to think whether I could use Relm in Niepce for the UI code. Not sure how easy it is to mix, I wouldn't want to rewrite it all.

Furthermore

In the near future, I'll want to be able to automate testing the app functionality, and I think the best is to embed a scripting language. I think it will be Python. pyo3, the Rust python binding crate seems to have everything I need, the longer plan is to be able to use it for automation at a later stage. The idea came from the way FreeCAD implement their test suite.

Thank you reading.