News

Rewriting keyboard shortcuts (accelerators) from scratch

GUI Usability

In my defining post, Darktable: crashing into the wall in slow-motion, I presented the trainwreck that the new “Great MIDI turducken” was. The purpose of this turducken1 was to rewrite the keyboard shortcuts system to extend it for MIDI devices.

To this day, I’m still mad about this enterprise of mass-destruction, here is a recap of he the reasons:

  1. it replaced in 2021 a keyboard shortcuts system that was pretty good, feature-complete, well tested, stable and coded in less than 1500 lines (comments included),
  2. …to add support for MIDI devices and PlayStation gamepads (!?!)…
  3. …but in my 2022 Darktable survey, one year after this new feature, over 1251 users who participated:
    • 81% of users didn’t have a MIDI device and didn’t plan to get one,
    • 2% didn’t even know what a MIDI device was.
    • 8% of users had a MIDI device but didn’t use it with Darktable,
    • 6% were considering maybe getting a MIDI device in the future,
    • 2% of users had a MIDI device they actually used in Darktable,
  4. the code was absolutely terrible, in terms of:
    • code quality: unlegible if/switch-case statements nested on 4 levels, in the middle of 1000-lines functions (I posted example snippets in my article),
    • code volume:
      • 3546 lines of code for Darktable 4.0,
      • 4397 lines of code for Darktable 5.0,
      • the increase in volume is a direct consequence of trying to fix bugs in an architecture that can’t be fixed because its complexity promotes more complexity. All that stems from the design, but solving issues created by complexity with adding more complexity is not a solution.
    • code complexity:
      • cyclomatic complexity :
        • 1088 for Darktable 4.0,
        • 1245 for Darktable 5.0 (details ),
      • cognitive complexity :
        • 1885 for Darktable 4.0,
        • 2098 for Darktable 5.0 (details ).
      • it is by far the most complex feature of the software, even though it does not operate on images. As a comparison, the second most complex feature is the EXIF metadata decoding, which has a cognitive complexity of 1348.
  5. it doesn’t decode key modifiers by design, but only deals with hardware key-strokes, which means:
    • “1” input from the numeric pad is decoded Keypad End,
    • “1” input from a French AZERTY keyboard is decoded Shift+&, or Shift+" on BÉPO,
    • you therefore need to duplicate all your number-based shortcuts for each way of entering a number, and be prepared for the shortcut settings window to not contain any actual number in the key combinations.
  6. the user-end design is absolutely terrible, with way too many actions and emulations to configure (“effects”), that are not even fully documented 4 years later (what is “ctrl-toggle” ? “right-activate” ?), and the shortcut configuration uses a weird split-window that doesn’t make any sense,
  7. the implementation is also terrible: the feature is aware of all the software GUI, and the software GUI is aware of the shortcuts code. There is no modularity here, and changing anything in the shortcuts code may have unexpected and undesired effect anywhere in the software.2 Just see the dependency graph below,
  8. several “shortcuts” (or MIDI bindings) can be attached to the same action, which means every user interaction has to lookup the whole list of available actions, inducing very inefficient shortcut handling, GUI lags in some cases and “unknown key combination” false positives in peculiar cases.
image
Non-decoded number keys and weird window splitting between "action" and "shortcut".
image

The dependency graph of src/gui/accelerators.c (Great MIDI turducken) before the rewrite. Guess why we call it “spaghetti code "… This makes it clear that there is a double-sided dependency between the accels code and the rest of the GUI code. This is a nightmare to maintain.

Welcome Ansel GPT !

Announcement

After I finally wired the whole website and docs to a water-tight translation workflow (using po4a on top of Hugo), which happens to use the exact same toolset and logic as the Ansel application, I got the idea of automating empty translations, first from the software translation files, then through ChatGPT API, which does a very fair job at translating Markdown syntax.

Working alone, you can’t rely on social loafing , so you have to be clever. You can see the list of things I have already automated in background for Ansel.

Welcome, developer documentation !

Development

Back in December 2019, I asked that someone took care of providing AppImages packages  for Darktable. The obvious benefit would have been enabling early testing, prior to release, from people who can’t build the source code themselves, as to hopefully provide early feedback and help debugging before releasing. This has never been a priority, which means that it was ok to have a pre-release and a post-release rush to fix bugs.

Fixing the pipeline cache and 10 years-old bugs

Development

Recap of the previous episodes

  1. Between 2020 and 2022, Darktable underwent a mass-destruction enterprise, by a handful of guys with more freetime and benevolence than actual skills,
  2. In 2022, I started noticing an annoying lag  between GUI interactions with sliders controls and feedback/update of said sliders. For lack of feedback stating that the value change was recorded, users could change it again, thereby starting additionnal pipeline recomputes and effectively freezing their computer because stupid GUI never said “got you, wait for a bit now”.
  3. I discovered that pipeline recomputations orders were issued twice per click (once on “button pushed”, once on “button released” events), and once again for each mouse motion, but also that the GUI states were updated seemingly after pipe recompute.
  4. I fixed that by almost rewriting the custom GUI controls (Bauhaus lib). I thought that preventing reckless recompute orders was gonna solve the lag : it didn’t. Then, I discovered that requesting a new pipeline recompute before the previous ended waited for the previous to end, despite a shutdown mechanism implemented many years ago that should have worked.
  5. I fixed that by implementing a kill-switch mechanism on pipelines, following comments in the code from the 2010’s and internal utilities that may well have never worked. This did not always work because the kill order came often with a noticeable delay. Once again, the GUI lag was not fixed.

Rewriting the import tool

Development Redesign

Ansel inherits from Darktable its database backbone: the non-destructive editing histories are saved per-picture into an SQLite database, along with metadata and other user-defined data. Making the database aware of new pictures is done through “importing” pictures from a disk or a memory card. That’s where the import tool comes.

Unfortunately, the Darktable importer is another thing that was butchered circa 2020 and turned into something deeply disconcerning, as it is a file browser that resembles no previously-known file browser, and manages to lack basic features (like Ctrl+F or EXIF preview) while still being bloated with useless ones (see below). This is where we loose many a future user, and it is only step 0 of the workflow. What a great showcase of what a “workflow app” can do !

Implementing kill-switch on pipeline

Development

I have thought, for a very long time, that there was some kill-switch mechanism on the pixel pipeline. The use case is the following :

  1. you are changing a module parameter,
  2. the previews (the central darkroom one and the thumbnail in left panel, also used for histogram and color pickers) recompute their pipeline to account for that change,
  3. one of the previews finishes rendering before the other, and the result is obviously not what you wanted,
  4. you change again the module parameter, without waiting for the recomputation to finish.

In that case, you want to kill all active pipelines because their output will not be used, and start recomputing everything immediately with new parameters. Except Darktable doesn’t do that, it lets the pipeline finish before restarting it, and looking at the comments in the source code, it seems to be a fairly recent regression and not the originally intended behaviour.

Un-darktable-ing GUI controls

Development

Darktable has its own GUI widgets library, for sliders and comboboxes (aka drop-down menus or selection boxes), called Bauhaus (in the source code, it’s in src/bauhaus/bauhaus.c). While they use Gtk as a backend, Bauhaus are custom objects. And like many things in Darktable, custom equals rotten.

In 2022, ‍I noticed parasite redrawings and lags , when using them, leading to a frustrating user experience : the widget redrawing seemed to wait for pipeline recomputations to complete, which meant that users were not really sure their value change was recorded, which could lead them to try again, starting another cycle of expensive recomputation, and effectively freezing their computer for several very frustrating minutes of useless intermediate pipeline recomputations.

Changes in distribution support for Linux AppImage package

Announcement

Rawspeed (the library providing the decoders for camera raw files) has deprecated support for GCC < 12. As a result, I can no longer build the AppImage on Ubuntu 20.04 (using Github runners) but I have to build it on 22.04.

It means any Linux distribution having libc older than 2.35 will not be able to start the new AppImages starting today. That should not affect most users running distributions upgraded in 2021 or more recently. Ubuntu 20.04 and other LTS/old stable distributions (Debian stable) may be affected.

Explaining Ansel redesign of module groups

Design

If you come from Darktable, you may be used to this in the darkroom:

image

while Ansel offers you this:

image

This is no accident, and it’s time to explain why, and why this will not be extended with customization options.

New build options for Linux

Development

I accidentally discovered that the Linux build script used a “package” build, meaning the CPU optimizations are limited to generic ones in order to produce portable binaries that can be installed on any x86-64 platform. By “using”, I mean the package build was not explicitely disabled, so it was enabled by default.

Anyway, this is now disabled by default, since the actual packages (.exe and .appimage) are not built through that script, which is primarily meant to help end-users. To get the previous behaviour back, you would need to run:

Dev diary #2 : introducing Chantal

Development

2022 was so bad in terms of junk emails and noise that I started the Virtual Secretary , a Python framework to write intelligent email filters by crossing information between several sources to guess what incoming emails are and whether they are important/urgent or not. When I’m talking about junk emails, it’s also Github notifications, pings on pixls.us (thank God I closed my account on that stupid forum), YouTube, and direct emails from people hoping to get some help in private.

Dev diary

Development

It’s been roughly 3 months that I rebranded “R&Darktable” (that nobody seemed to get right), into “Ansel”, then bought the domain name and created the website from scratch with Hugo (I had never programmed in Golang before, but it’s mostly template code).

Then I spent a total 70 h on making the nightly packages builds for Windows and Linux work for continuous delivery, something that Darktable never got right (“you can build yourself, it’s not difficult”), only to see the bug tracker blow up after release (nothing better than chaining the pre-release sprint with a post-release one to reduce your life expectancy).

Darktable : crashing into the wall in slow-motion

What happens when a gang of amateur photographers, turned into amateur developers, joined by a bunch of back-end developers who develop libraries for developers, decide to work without method nor structure on an industry software for end-users, which core competency (colorimetry and psychophysics) lies somewhere between a college degree in photography and a master’s degree in applied sciences, while promising to deliver 2 releases each year without project management ? All that, of course, in a project where the founders and the first generation of developers moved on and fled ?

Search

You can also ask Chantal, the AI search engine.