Hub's wlogZola2023-10-01T00:00:00+00:00https://www.figuiere.net/hub/wlog/atom.xmlDev Log September 20232023-10-01T00:00:00+00:002023-10-01T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/dev-log-sept-2023/<p>It's October 2023.</p>
<h2 id="niepce">Niepce</h2>
<p>Realy very little.</p>
<p>Fixed a cosmetic issues with icons in the workspace. The short version
is that for symbolic icons to work, they must be in a "standard" path
even if they are loaded from resources.</p>
<p>Also some minor dependency checks, etc.</p>
<h2 id="lrcat-extractor">lrcat-extractor</h2>
<p><a href="https://github.com/hfiguiere/lrcat-extractor"><code>lrcat-extractor</code></a> is
my Rust crate to export Lightroom™ catalogs. It's used in Niepce. Just
a few bits of maintenance, like replacing <code>docopt</code> with <code>clap</code> for the
dumper tool, and using <code>thiserror</code>.</p>
<h2 id="aplib-extractor">aplib-extractor</h2>
<p><a href="https://github.com/hfiguiere/aplib-extractor"><code>aplib-extractor</code></a> is
the sibling of <code>lrcat-extractor</code>, a crate to export Aperture™
libraries. This is actually the oldest and one of my first projects in
Rust, which really shows. I worked on adding missing features so that
I can implement the importer in Niepce, including listing the volumes.</p>
<p>The reasoning in implementing the import is to help refine the data
model in Niepce to be able to handle the structure of an Aperture™
library as it offer organizational features that Ligthroom™
doesn't. This actually might lead to deeper changes in Niepce internal
design.</p>
<p>Once the importer works, I will release the crate officially as I'll
know the API is sound.</p>
<h2 id="dia-on-gtk3">Dia on Gtk3</h2>
<p>Two years after I started it, and mostly drop the ball, the <a href="/hub/wlog/dia-gtk3/">GTK 3
port of Dia has been merged</a>.</p>
<p>I also fixed a few other small issues, including some memory leaks.</p>
Dia with GTK 32023-09-24T00:00:00+00:002023-09-24T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/dia-gtk3/<p>If you are running <a href="https://wiki.gnome.org/Apps/Dia">Dia</a> from the
nigthly GNOME flatpak, the last update brought a big change: it is now
a GTK 3 app. The UI shouldn't be much different, just some cosmetic
adjustments due to theming and other like widget spacing. Also it now
work with Wayland and HiDPI.</p>
<p>It is something I started over two years ago, and that for some reason
I left on the back burner. So I did a final push and many thanks to
Zander for reviewing and <a href="https://gitlab.gnome.org/GNOME/dia/-/merge_requests/85">merging
it</a>. Now we
shall hunt for regression. I already have a <a href="https://gitlab.gnome.org/GNOME/dia/-/merge_requests/100">fix for the touchpad
scrolling</a>.</p>
<p>The version is numbered starting 0.98. So if it is Dia 0.98 or higher,
then it's GTK 3.</p>
<p>There is still some more stuff to do. Fix a regression in the
navigator widget, build without deprecation post GTK 3.8, etc.</p>
Dev Log August 20232023-09-02T00:00:00+00:002023-09-02T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/dev-log-august-2023/<p>Didn't really do anything on Niepce in August, so no updates on that
front. However I worked on a few other things.</p>
<h2 id="libopenraw">libopenraw</h2>
<p>A lot of work done on it. See my <a href="/hub/wlog/libopenraw-rust-capi/">other wlog
post</a>. The short version is that I
should look towards releasing 0.4.0 sometime soon.</p>
<p>Since that last post, I have added a long standing to-do item: code to
generate test cases so I can run a non regression test suite on
existing files. However I get hit with flaws in the various XML serde
crates.</p>
<h2 id="abiword">AbiWord</h2>
<p>Did some work on
<a href="https://gitlab.gnome.org/World/AbiWord/">AbiWord</a>. Nothing ground
breaking, but I have a goal to try to release the next 3.0.x with one
or two bug fixes (UI), and then what I call <em>3.next</em> (likely 3.2) that
will focus on internal changes (stability) and UI fixes (anything
back-portable to 3.0.x will get back-ported).</p>
<h3 id="done">Done</h3>
<ul>
<li>Some code cleanup.</li>
<li>Removed the use of <code>boost</code> in many places where the standard C++
library would work.</li>
<li>Use C++17 more.</li>
<li>Making the build system less recursive. It's less complex and should
be more parallel.</li>
<li>Removed some Gtk3 construct that are deprecated in provision of a
future Gtk4 port.</li>
<li>More removal of the legacy containers.</li>
<li>Rewrote the toolbars to use plain buttons and a <code>GtkBox</code> instead of
<code>GtkToolItem</code>. The look is slightly different.</li>
<li>Fixing some Gtk3 bug: the table creation widget was not behaving
properly. Will be on stable too (3.0.x)</li>
<li>Fixing some bugs with styling. (also on 3.0.x)</li>
</ul>
libopenraw Rust with C API2023-08-28T00:00:00+00:002023-08-28T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/libopenraw-rust-capi/<p><a href="/hub/wlog/release-day/">As I previously talked about</a>, I started
porting <a href="https://libopenraw.freedesktop.org/">libopenraw</a> to Rust. It
is now in a state where it has more feature than the original.</p>
<p>When I started writing this post, I didn't have 100% of the code Rust,
but since I have removed the last bit of C++, for which I had cut
corners to make sure to have a functional API for C.</p>
<p>The only C++ code left is the various utilities and the C++ test suite
to validate.</p>
<h2 id="the-goal">The goal</h2>
<p>The goal of the Rust rewrite is to have the digital camera raw
parsing library written in Rust instead of C++, while still being
available with a C API.</p>
<p>The goal of the updated C API is to be close to the original
API. However it's also a good time to do some breaking
changes. Notably most of the "objects" are now immutable.</p>
<h2 id="rewrite">Rewrite</h2>
<p>I did the rewrite in a branch, aiming to provide the same level of
functionality as the C++ code. One of the first step was to rewrite
the test suite to use the same data set. Doing so did allow verifying
the consistency in behaviour, a progressively implement all the
features and formats.</p>
<p>The C++ code use inheritance a bit to override some of the behaviours
based on which file format it was. One of the thing most camera raw
file have in common is that they are mostly a TIFF file. However Rust
doesn't do object-oriented. It has traits that allow implementing some
level of polymorphism, but in that case the concept had to be
rethought a little bit.</p>
<h3 id="benefits">Benefits</h3>
<p>This is where Rust shines.</p>
<p>First there are a lot of things Rust, or the ecosystem around, did for
me. In C++ I had re-implemented a stream system to allow IO on buffers
and handling endianess. In Rust you can just read from a slice (a
fixed size array of data) with the <code>Read</code> trait, and there are
built-in functions to read endian-specific values. I still have the
memory of trying to figure out which include to add depending on the
UNIX flavour, between Linux, macOS and the BSD.</p>
<p>Second, the <code>Debug</code> trait. Just derive <code>Debug</code> (it's a simple macro)
and you can "print" an type like that, using string formats. In C++,
well, it's a lot of work. And on enum types it will print a human
readable value, ie the one you write in code.</p>
<p>Third, the safety. A lot of the safety feature of Rust prevent
mistake. And at runtime, the bounds checking catch of a lot of things
too. Being required to use <code>Option<></code> or <code>Result<></code> to handle cases
where in C++ you'd get some null value.</p>
<p>At that point, a few bugs I identified porting / rewriting the code
made their way to the 0.3.x series in C++.</p>
<h3 id="drawbacks">Drawbacks</h3>
<p>libopenraw requires a Rust compiler (technically it already did, but I
know some packagers that did disable Rust. This mean that non
current architecture might not be supported. To me it's not a big
issue, I target modern computers.</p>
<h2 id="testing">Testing</h2>
<p>As mentioned I rewrote the test suite with the same data set. This is
an essential part of making sure the features work as previously.</p>
<p>I also rewrote <code>ordiag</code> and the dumper <code>ordumper</code>. The dumper allow
analyzing the structure of the file, and I didn't have this one in C++
(instead I had a more primitive <code>exifdump</code>). The dumper is heavily
inspired from <a href="https://github.com/hfiguiere/exifprobe"><code>exifprobe</code></a>
that has served me well and that I forked. Really I can see the amount
of work I didn't need to do with Rust.</p>
<p>To add to this I wrote
<a href="https://gitlab.freedesktop.org/libopenraw/libopenraw-viewer"><code>libopenraw-viewer</code></a>,
a small Rust application to view the content of camera raw files. This
allow much more easily to see the output. This has helped me to find
fundamental bugs in some of the parsing that led to some fixes
"upstream", namely into the C++ version (0.3.x branch). I should have
done that a long time ago. This also allow me to test the Rust API.</p>
<h2 id="c-api-adaptation">C API adaptation</h2>
<p>Last but not least I had to provide a C API. This allow using the
library.</p>
<p>Rust to C ffi has limitations. You can basically pass numbers,
pointers, and eventually simple structures.</p>
<p>The libopenraw API did return several types of "ref" which are just
pointers to opaque types. The idea was always to only have opaque
types through the API, which internally were C++ instances.</p>
<p>One of the key change is that the only object that can be explicitly
be created with the API is <code>ORRawFileRef</code>, because it's the entry
point. Very few need to be released, most are held by the containing
objects.</p>
<p>Some other constraints of the C API directed some choices in the Rust
API.</p>
<ul>
<li>Raw files are no longer <code>Box<></code> but <code>Rc<></code> due to the need to retain
them for the iterator.</li>
<li><code>Metadata::String()</code> contain a <code>Vec<u8></code> instead of a <code>String</code> to
allow for the NUL terminated strings in the C API. They are maybe
not NUL terminated but ASCII.</li>
</ul>
<h2 id="new-features">New features</h2>
<p>Meanwhile I added a few new features:</p>
<ul>
<li>extracting the white balance on most files (saveral Nikon are not
yet handled).</li>
<li>color converting from the camera space to sRGB on rendering.</li>
<li>a multi stage processing pipeline.</li>
</ul>
<p>This is still not enough to have a complete processing pipeline, but
it's a start. It's going towards the only two issue left in the issue
tracker. Not that I don't expect more but it's a nice goal post.</p>
<h2 id="integration">Integration</h2>
<p>I <a href="https://github.com/dbrgn/miniaturo/pull/15">submitted a PR</a> for
<a href="https://github.com/dbrgn/miniaturo/">Miniaturo</a> to use the Rust
version of the library. This is not ready to be merged, but this
actually allowed me to fix a few API bits. The new Rust API is
relatively close to the old API that was the Rust to C bindings.</p>
<div class="footnote-definition" id="norust"><sup class="footnote-definition-label">1</sup>
<p>See <a href="https://gitlab.freedesktop.org/libopenraw/libopenraw/-/issues/13">issue
13</a></p>
</div>
<div class="footnote-definition" id="threads"><sup class="footnote-definition-label">2</sup>
<p>This is likely to change when I make libopenraw
multi-thread compatible.</p>
</div>
Niepce July 2023 updates2023-08-01T00:00:00+00:002023-08-01T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-july-2023-update/<p>This is the July 2023 update for Niepce.</p>
<h1 id="the-importer">The importer</h1>
<p>Where we left, the workspace tree view didn't display the hierarchy.</p>
<p>First, I discovered bug in the SQL triggers for folder path update. I
was missing the <code>AFTER</code> keyword to have it run after the update.</p>
<h2 id="workspace">Workspace</h2>
<p>Second, I need to specify a parent when adding items to the model,
then locate the parent, add to it. The problem is that we get a list
of folders in some order (I can order by any of the SQL columns). The
problem is adding an item to a parent that is not yet int the
model. There are few ways to go about it.</p>
<ol>
<li>Sort the folder list in order of a flattened tree. To be fair my
SQL skills are not good enough, and I'm not even sure I can do that
in sqlite. This would solve most of the problems.</li>
<li>Sort the folder list once received. But this might not always work.</li>
<li>Handle the case in the model: add with a placeholder parent and
re-parent as needed when the parent is added.</li>
</ol>
<p>For now I chose 3. The risk is that if the parent doesn't exist then
the tree will stay lingering. It's just the view though.</p>
<p>Here is the result:</p>
Niepce June 2023 updates2023-07-01T00:00:00+00:002023-07-01T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-june-2023-update/<p>This is the June 2023 update for Niepce.</p>
<h1 id="the-importer">The importer</h1>
<p>Back where we left, still working on the import.</p>
<p>It looks like there is more work than anticipated to be able to import
a tree a files.</p>
Life update2023-06-30T00:00:00+00:002023-06-30T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/update/<p>If you are looking for a Software Engineer with strong skills in C,
C++, Rust and JavaScript, with a strong FLOSS background, I am
available to hire.</p>
<p><a href="https://www.figuiere.net/hub/cv/en/">My résumé</a></p>
Niepce May 2023 updates2023-06-02T00:00:00+00:002023-06-02T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-may-2023-update/<p>This is the May 2023 update for Niepce.</p>
<p>Life comes at you fast. And hit hard. tl;dr not as much progress as I
wished: I had to put this project a bit more on the sideline.</p>
<p>This will be a short update.</p>
<h1 id="the-importer">The importer</h1>
<p>Some small bits:</p>
<p>Some fixing in the metadata processing on import, notably a better
handling of raw files. Turns out the previous logic broke getting
metadata from video files.</p>
<p>Also fixing some <a href="https://github.com/felixc/rexiv2/pull/70"><code>rexiv2</code></a>
/ <a href="https://github.com/felixc/gexiv2-sys/pull/25"><code>gexiv2-sys</code></a> bugs
that are mostly memory leaks.</p>
<p>I am pondering directly binding Exiv2 now that 0.28 got rid of
<code>auto_ptr<></code> that had been deprecated for over a decade. <code>cxx</code> should
make this easier. This would automatically resolve the problem above,
and I don't need to bind all the API, just what I need.</p>
<h2 id="forecast">Forecast</h2>
<p>To move forward the importer, I need to fix the recursive creation of
folders (it currently flatten them to a single level).</p>
<h1 id="misc">Misc</h1>
<p>There are always the other fixes.</p>
<h2 id="fedora-38">Fedora 38</h2>
<p>I pulled the trigger and updated to Fedora 38. And Niepce failed to
build because of a <a href="https://github.com/rust-lang/rust-bindgen/issues/2312">bug with bindgen with clang
16</a>, that was
already fixed, triggered by <code>libgphoto2-sys</code>. Submitted <a href="https://github.com/maxicarlos08/gphoto2-rs/pull/60">the PR for
the crate</a> and we
are good to go. The short version is that clang 16 sent different data
for anonymous enums, that bindgen 0.60 couldn't handle. But at that
bindgen 0.65 was fine.</p>
<p>This is the reason why I always check into git the generated bindings
and update them as needed, instead of doing it at build time.</p>
<h2 id="application-id">Application ID</h2>
<p>I have been using <code>org.gnome.Niepce</code> as an application ID. While it is
hosted in the main namespace repositories (it was back in the days of
Subversion, to which I am thankful), Niepce is not a core
app. Policies with the GNOME project do not allow using that namespace
for non core apps. So I had a perform a global change rename. Not a
big deal, and it doesn't change anything for users since there is no
release. I just needed to get this out of the way.</p>
<h2 id="libopenraw">libopenraw</h2>
<p>Pushed a bit on the Rust port to implement metadata extraction. This
is driven by the goal of not having three different libraries. Still
some parity gaps with the C++ code, but it's closing in. I hope to be
able to release 0.4.0 based on the Rust code.</p>
<p>Thanks you for reading.</p>
Niepce April 2023 updates2023-05-03T00:00:00+00:002023-05-03T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-april-2023-update/<p>This is the April 2023 update for Niepce. Between outages caused by an
unseasonbly ice storm, squirrels chewing cable, I discovered how
painful is being off the grid. This is not the excuse, just the events
that lead to downtime and April not being very productive.</p>
<p>The importer moved a little bit forward. I tried to use the brand new
"sort by date" importer tool, that is used to test and exercise the
logic. The improved importer address a few long standing issues,
including not using libgphoto2 for USB Mass Storage, including flash
card readers. This was a shortcut I had taken and the result was
suboptimal. The new approach is to use libgphoto2 to find the device,
and then switch to pure filesystem operations. That was <a href="https://gitlab.gnome.org/GNOME/niepce/-/issues/26">issue
26</a>.</p>
<p>I picked up my camera which I haden't done much since the pandemic
started. After a firmware upgrade on the Fujifilm X-T3 (it's a 4 year
old model, and the firmware is from this year, unlike most
smartphones), I notice a new feature that allow setting a picture as
favourite. My first question was "how is it stored?". I put that on my
list for later.</p>
<p>After taking some pictures of the newly bloomed spring flowers, I
tried the importer. The new files cause a bug with metadata making the
importer unable to determine the creation date ; I hit this when
trying to sort these new pictures.</p>
Niepce March 2023 updates2023-04-01T00:00:00+00:002023-04-01T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-march-2023-update/<p>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.</p>
<p>Continuing with the renderer / previewer cache.</p>
<p>I had to move <code>ncr</code> to Rust. I didn't port it all, but the
widget and the main API are now in a Rust crate <code>npc-craw</code>, 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.</p>
<p>In the same way, I also ported most of the <em>darkroom</em> module to
Rust. This module is the one that will allow the image editing and
currently only handle displaying the images.</p>
<p>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.</p>
Integrating the RawTherapee engine2023-03-18T00:00:00+00:002023-03-18T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/integrating-rtengine/<p><a href="http://rawtherapee.com/">RawTherapee</a> is one of the two major open
source RAW photo processing applications, the other is Darktable.</p>
<p>Can I leverage RawTherapee RAW processing code for use in Niepce? Yes
I can.</p>
<p>So let's review of I did it.</p>
Niepce February 2023 updates2023-03-02T00:00:00+00:002023-03-02T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-february-2023-update/<p>This is the February 2023 update.</p>
<p>Not as much direct progress as I wished.</p>
<p>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.</p>
<p>Several challenges presented themselves with linked the app from Rust.</p>
<ol>
<li>We have to invert the dependency. We'd build the Rust code as a
library, generate the headers for the <code>cxx</code> 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.</li>
<li>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.</li>
</ol>
<p>Otherwise, for the two previous topics, namely the importer and the
previewer.</p>
Implementing i18n-format, a Rust procedural macro2023-02-05T00:00:00+00:002023-02-05T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/implementing-i18n-format/<p>This will relate my short learning journey in implementing a
procedural macro in Rust:
<a href="https://www.figuiere.net/hub/wlog/i18n-format/">i18n-format</a>.</p>
<h2 id="the-problem">The problem</h2>
<p>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 <a href="https://www.figuiere.net/hub/wlog/implementing-i18n-format/niepce-suite.pot"><code>rust-gtk-template</code></a> 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.</p>
<p>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 <a href="https://savannah.gnu.org/bugs/?56774">the patch to fix it is stuck in
review</a>.</p>
<p>While it mostly works, the lack of support cause one thing: the
<code>getttext!</code> macro that allow the use of localized strings as format
is ignored by the <code>xgettext</code> command used to extract and strings and
generate the PO template. It is the <code>!</code>, 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 <code>format!</code>, which is why <code>gettext!</code> exists in the first place.</p>
<p>Until <code>xgettext</code> 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.</p>
<p>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.</p>
<p>The idea is as follow: convince <code>xgettext</code> to recognize the string. It
should look like a plain function, while we need to call a macro.</p>
Niepce January 2023 updates2023-02-02T00:00:00+00:002023-02-02T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-january-2023-update/<p>This is the January 2023 update.</p>
<p>We start the year by a Rust implementation of the file import. It
landed very early as the final stretch of work in 2022.</p>
<p>Then a lot of cleanups, removing no longer needed <code>cxx</code> bindings and
no longer used C++ code. This also allow removing some "wrapper" type
used in the Rust code base.</p>
<p>The other <code>gphoto2-rs</code> patch has also been merged.</p>
i18n-format for Rust2023-01-22T00:00:00+00:002023-01-22T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/i18n-format/<p>A quick announcement for
<a href="https://crates.io/crates/i18n-format/"><code>i18n-format</code></a>, 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.</p>
<p>The goal is to allow the use of <code>gettext!</code> and <code>ngettext!</code> while
xgettext can still extract the strings.</p>
<p>Simple use:</p>
<pre data-lang="rs" class="language-rs "><code class="language-rs" data-lang="rs">use i18n_format::i18n_fmt;
let number = 1;
let s = i18n_fmt! {
i18n_fmt("This is number {}, make it so !", number)
};
</code></pre>
<p>In your <code>po/meson.build</code>, make sure to have:</p>
<pre data-lang="meson" class="language-meson "><code class="language-meson" data-lang="meson">i18n.gettext(gettext_package,
args [
'--keyword=i18n_fmt',
'--keyword=i18n_nfmt:1,2'
],
preset: 'glib')
</code></pre>
<p>If you use the regular
<a href="https://gitlab.gnome.org/World/Rust/gtk-rust-template/"><code>gtk-rust-template</code></a>,
that's probably all that needs to happen.</p>
<p>Don't forget to check <a href="https://docs.rs/i18n-format/0.2.0/i18n_format/">the
documentation</a>, or
<a href="https://github.com/hfiguiere/i18n-format">the code</a>.</p>
Introducing Toot That!2023-01-03T00:00:00+00:002023-01-03T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/toot-that/<p>Introducing <em>Toot That!</em>.</p>
<p>It's a small WebExtension (browser add-on) for Firefox.</p>
<p>It's the successor of <a href="https://github.com/hfiguiere/tweet-that"><em>Tweet
That!</em></a> but for use with
Mastodon (the Fediverse).</p>
<p>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.</p>
<p>Install it as a <a href="https://addons.mozilla.org/en-US/firefox/addon/toot-that/">Firefox
Add-ons</a>.</p>
Niepce December 2022 updates2023-01-02T00:00:00+00:002023-01-02T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-december-2022-update/<p>Happy new year !</p>
<p>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.</p>
Niepce November 2022 updates2022-12-02T00:00:00+00:002022-12-02T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-november-2022-update/<p>Here are the updates in <a href="https://gitlab.gnome.org/GNOME/niepce">Niepce
development</a> for
November 2022.</p>
<p>I'll try to bring these updates on a more regular basis. In case you
missed it, there was a <a href="https://www.figuiere.net/hub/wlog/niepce-update/">May update</a>.</p>
Fall of releases2022-10-22T00:00:00+00:002022-10-22T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/fall-of-releases/<p>A couple of Rust crate releases.</p>
<p>Now that the new glib-rs (and gtk-rs) are out, it's time for an update
of <a href="https://crates.io/crates/gudev"><code>gudev</code></a> Rust bindings using the
newer version of <code>glib-rs</code>.</p>
<p>At the same time I updated
<a href="https://crates.io/crates/midi-control"><code>midi-control</code></a> to use a newer
version of <code>midir</code> to iron out a <code>cargo audit</code> warning.</p>
<p>Available from <a href="https://crates.io/">crates.io</a>.</p>
Introducing Compiano2022-09-23T00:00:00+00:002022-09-23T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/introducing-compiano/<p>I previously <a href="https://www.figuiere.net/hub/blog/?2020/07/11/882-introducing-minuit">introduced
Minuit</a>. Later
I got notified that there was also a music education application for
KDE named <a href="https://minuet.kde.org/">Minuet</a>. So it was natural to yield
the name. It's relatively easy to do when you haven't had a release.</p>
<p>I decided to rename my application <em>Compiano</em>, a portemanteau word for
<em>Computer Piano</em>.</p>
RTKit, portals, and Pipewire2022-08-12T00:00:00+00:002022-08-12T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/rtkit-portal-pipewire/<p>Peeling an onion, or how a bug report in a flatpaked application
lead to fixes in three different part of the stack, but no change in
the application itself.</p>
Release day2022-06-25T00:00:00+00:002022-06-25T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/release-day/<p>It's release day, sorta. Both libopenraw and Exempi got a new release
within two days. Here is what's up.</p>
Update on Niepce2022-05-25T00:00:00+00:002022-05-25T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/niepce-update/<p>Here we go, when I started <a href="https://gitlab.gnome.org/GNOME/niepce">that
project</a> in 2006, I had plenty
of ideas. I still have, but everything else is in the way, including
me.</p>
<p>Since there have been some amazing apps, like
<a href="https://www.rawtherapee.com/">RawTherapee</a>,
<a href="https://www.darktable.org/">Darktable</a>, and possibly some other I
miss, apps fullfilling some of the uses I envisioned for Niepce back
then. Not to mention a few other apps that did just disappear ; that's
life, it's hard to find maintainers or keep being motivated.</p>
New Again2022-05-24T00:00:00+00:002022-05-24T00:00:00+00:00Hubert Figuièrehttps://www.figuiere.net/hub/wlog/new-again/<p>Old is new again. Apparently my blog was broken following a PHP
upgrade on the server. tl;dr PHP 8 broke things and code had to be
changed. I don't do PHP so I had to guess (I can read it, patch it,
but it's a lot of tries).</p>