This is the March 2023 update for Niepce. This is not an April's fool, and this is not the year I can announce a release on April's fool day. Sorry about that.

Continuing with the renderer / previewer cache.

I had to move ncr to Rust. I didn't port it all, but the widget and the main API are now in a Rust crate npc-craw, the fourth one in the workspace. The goal of this crate is to provide the interface to the rendering pipeline. Some of the work included moving away from Cairo surface and using GdkTextures instead. The main pipeline is still the original C++ code using GEGL, it's easier for me to bind the C++ code than to write wrappers for GEGL.

In the same way, I also ported most of the darkroom module to Rust. This module is the one that will allow the image editing and currently only handle displaying the images.

All of this was necessary to finish the render / previewer integration and making it work asynchronously: the image rendering happen in the background without freezing the UI. There are still some issues but it on overall, it works well.

RawTherapee is one of the two major open source RAW photo processing applications, the other is Darktable.

Can I leverage RawTherapee RAW processing code for use in Niepce? Yes I can.

So let's review of I did it.

This is the February 2023 update.

Not as much direct progress as I wished.

One big change is that now the binary is linked from Rust. And at the same time the autotools buid system is gone. The latter came first, as to not have to ignore it when doing the former.

Several challenges presented themselves with linked the app from Rust.

1. We have to invert the dependency. We'd build the Rust code as a library, generate the headers for the cxx bridge and then build the C++ code, and link it. Instead we generate the headers, build the C++ code as libraries and then the Rust code.
2. We have to figure some tricks: the Rust executable needs to link to some system libraries called directly from the C++ code, and also need to link to asan if needed.

Otherwise, for the two previous topics, namely the importer and the previewer.

This will relate my short learning journey in implementing a procedural macro in Rust: i18n-format.

The problem

Building Rust applications means having to deal with localization, ie allowing the UI to be translated in other languages. This is a big deal for users, and thanks to existing tooling, if you use gtk-rs and if you use the rust-gtk-template to boostrap your project you should be all set. The GNOME community has an history of caring about this and most of the infrastructure is here.

However there is one sore point into this: gettext, the standard package used to handle strings localization at runtime doesn't support Rust. For some reason the patch to fix it is stuck in review.

While it mostly works, the lack of support cause one thing: the getttext! macro that allow the use of localized strings as format is ignored by the xgettext command used to extract and strings and generate the PO template. It is the !, a part of the macro invocation syntax in Rust, that is the blocker. Another problem is that in Rust, for safety reasons, you can only pass a string literal to format!, which is why gettext! exists in the first place.

Until xgettext is fixed, either these strings are missed in the localization process, or you end up reimplementing it with less flexibility. That's what some applications do.

What if I implement a macro that would allow using a function syntax and still use the macro underneath? Oh boy, that mean I need to implement a procedural macro, something I have been dreading because it looks like it has a steep learning curve. It's a topic so complicated that it is glanced over by most books about Rust. Turns out it wasn't that difficult, thanks to a great tooling.

The idea is as follow: convince xgettext to recognize the string. It should look like a plain function, while we need to call a macro.

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.

A quick announcement for i18n-format, a Rust crate to help with string localization. While it's not GNOME specific as it is only about gettext, I wrote it for GNOME applications.

The goal is to allow the use of gettext! and ngettext! while xgettext can still extract the strings.

Simple use:

use i18n_format::i18n_fmt;

let number = 1;
let s = i18n_fmt! {
    i18n_fmt("This is number {}, make it so !", number)
};

In your po/meson.build, make sure to have:

i18n.gettext(gettext_package,
  args [
    '--keyword=i18n_fmt',
    '--keyword=i18n_nfmt:1,2'
  ],
  preset: 'glib')

If you use the regular gtk-rust-template, that's probably all that needs to happen.

Don't forget to check the documentation, or the code.

Introducing Toot That!.

It's a small WebExtension (browser add-on) for Firefox.

It's the successor of Tweet That! but for use with Mastodon (the Fediverse).

It allows posting a link to the current tab to your chosen Mastodon instance. Only the server knows this is happening. The extension doesn't send anything else.

Install it as a Firefox Add-ons.

Happy new year !

Here is some udpdate on Niepce work done in December 2022. Mostly changes under the hood, but important ones to move forward with improving the features. The short version: it feels great to remove C++ code.

Here are the updates in Niepce development for November 2022.

I'll try to bring these updates on a more regular basis. In case you missed it, there was a May update.

A couple of Rust crate releases.

Now that the new glib-rs (and gtk-rs) are out, it's time for an update of gudev Rust bindings using the newer version of glib-rs.

At the same time I updated midi-control to use a newer version of midir to iron out a cargo audit warning.

Available from crates.io.