[TOC]
Ansel is a better future for Darktable, designed from real-life use cases and solving actual problems, by the guy who did the scene-referred workflow and spent these past 4 years working full-time on Darktable.
It is forked on Darktable 4.0, and is compatible with editing histories produced with Darktable 4.0 and earlier. It is not compatible with Darktable 4.2 and later and will not be, since 4.2 introduces irresponsible choices that will be the burden of those who commited them to maintain, and 4.4 will be even worse.
The end goal is :
- to produce a more robust and faster software, with fewer opportunities for weird, contextual bugs that can't be systematically reproduced, and therefore will never be fixed,
- to break with the trend of making Darktable a Vim editor for image processing, truly usable only from (broken) keyboard shortcuts known only by the hardcore geeks that made them,
- to sanitize the code base in order to reduce the cost of maintenance, now and in the future,
- to make the general UI nicer to people who don't have a master's in computer science and more efficient to use for people actually interested in photography, especially for folks using Wacom (and other brands) graphic tablets,
- to optimize the GUI to streamline the scene-referred workflow and make it feel more natural.
Ultimately, the future of Darktable is vkdt, but this will be available only for computers with GPU and is a prototype that will not be usable by a general audience for the next years to come. Ansel aims at sunsetting Darktable with something "finished", pending a VKDT version usable by common folks.
The virtual 0.0.0 pre-release
contains nightly builds, with Linux .Appimage and Windows .exe, compiled automatically
each night with the latest code, and containing all up-to-date dependencies.
Ansel is developped on Fedora, heavily tested on Ubuntu and fairly tested on Windows.
Mac OS and, to a lesser extent, Windows have known GUI issues that come from using Gtk as a graphical toolkit. Not much can be done here, as Gtk suffers from a lack of Windows/Mac devs too. Go and support these projects so they can have more man-hours put on fixing those.
Mac OS support is not active, because :
- the continuous integration (CI) bot for Mac OS breaks on a weekly basis, which needs much more maintenance than Linux or even Windows,
- only 4% of the Darktable user base runs it, and it's unfair to Linux and Windows users to allocate more resources to the minority OS,
- I don't own a Mac box to debug,
- I don't have an (expensive) developer key to sign .dmg packages,
- even Windows is not that much of a PITA to maintain.
A couple of nice guys are trying their best to fix issues on Mac OS in a timely manner. They have jobs, families, hobbies and vacations too, so Mac OS may work or it may not, there is not much I can do about it.
- User documentation, in particular:
- Contributing guidelines, in particular:
- Developer documentation (NEW)
- Project news
- Community forum
- Matrix chatrooms
- Support
Ansel was forked from Darktable after commit 7b88fdd7afe7b8530a992ae3c12e7a088dc9e992, 1 month before Darktable 4.0 release (output truncated to relevant languages):
$ cloc --git --diff 7b88fdd7afe7b8530a992ae3c12e7a088dc9e992 HEAD
github.com/AlDanial/cloc v 2.02 T=227.18 s (2.9 files/s, 4772.1 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C
same 0 0 22928 208021
modified 266 0 964 7059
added 19 2072 2955 18146
removed 48 6747 5243 51264
C/C++ Header
same 0 0 5018 11746
modified 92 0 195 476
added 17 599 857 2565
removed 9 296 704 2487
C++
same 0 0 791 6746
modified 8 0 20 170
added 1 321 280 2210
removed 1 318 243 2020
CSS
same 0 0 0 0
modified 0 0 0 0
added 3 324 357 1794
removed 13 419 519 9575
...
--------------------------------------------------------------------------------
SUM:
same 0 0 56961 491412
modified 486 0 111210 48363
added 88 15173 42295 121274
removed 186 25488 96370 187742
--------------------------------------------------------------------------------
$ cloc --git 7b88fdd7afe7b8530a992ae3c12e7a088dc9e992
github.com/AlDanial/cloc v 2.02 T=3.70 s (286.4 files/s, 327937.4 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C 439 51319 37122 303148
C/C++ Header 284 7286 11522 24848
C++ 11 1489 1138 9899
CSS 20 564 617 10353
...
--------------------------------------------------------------------------------
SUM: 1160 221925 280733 832393
--------------------------------------------------------------------------------
$ cloc --git HEAD
github.com/AlDanial/cloc v 2.02 T=3.70 s (286.4 files/s, 327937.4 lines/s)
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C 410 46644 34834 270030
C/C++ Header 292 7589 11675 24926
C++ 11 1492 1175 10089
CSS 10 469 455 2572
...
--------------------------------------------------------------------------------
SUM: 1062 211610 243588 800478
--------------------------------------------------------------------------------
The volume of C code has therefore been reduced by 11%, the volume of CSS (for theming)
by 75%. Excluding the pixel operations (cloc --fullpath --not-match-d=/src/iop --git),
the C code volume has reduced by 15%.
The cyclomatic complexity of the project has also been reduced reduced:
| Metric | Ansel Master | Darktable 4.0 | Darktable 5.0 |
|---|---|---|---|
| Cyclomatic complexity | 48806 | 56170 | 59377 |
| Cognitive complexity | 62122 | 72743 | 77039 |
| Lines of code | 318741 | 361046 | 370781 |
| Ratio of comments | 12.3% | 11.5% | 11.7% |
Those figures are indirect indicators of the long-term maintainability of the project:
- comments document the code and are used by Doxygen to build the dev docs,
- code volume and complexity make bugs harder to find and fix properly, and lead to more cases to cover with tests,
- code volume and complexity prevent from finding optimization opportunities,
- let's remember that it's mostly the same software with pretty much the same features anyway.
Dealing with growing features should be made through modularity, that is splitting the app features into modules, enclosing modules into their own space, and make modules independent from each other's internals. We will see below how those "modules" behave (spoiler 1: that this did not happen), (spoiler 2: feel free to go the dev docs, where all functions have their dependency graph in their doc, to witness that "modules" are not even modular, and the whole application is actually aware of the whole application).
Let's see a comparison of Ansel vs. Dartable 4.0 and 5.0 complexity per file/feature (figures are: cyclomatic complexity / lines of code excluding comments - lower is better) :
| File | Description | Ansel Master | Darktable 4.0 | Darktable 5.0 |
|---|---|---|---|---|
src/common/selection.c |
Database images selection backend | 57 / 258 | 62 / 342 | 62 / 394 |
src/common/act_on.c |
GUI images selection backend | 12 / 32 | 80 / 297 | 80 / 336 |
src/common/collection.c |
Image collection extractions from library database | 418 / 1731 | 532 / 2133 | 553 / 2503 |
src/develop/pixelpipe_hb.c |
Pixel pipeline processing backbone | 442 / 2149 | 473 / 2013 | 553 / 2644 |
src/develop/pixelpipe_cache.c |
Pixel pipeline image cache* | 29 / 153 | 55 / 242 | 95 / 368 |
src/develop/develop.c |
Development history & pipeline backend (original) | - | 600 / 2426 | 628 / 2732 |
src/develop/develop.c |
Development pipeline backend (refactored) | 280 / 1020 | - | - |
src/develop/dev_history.c |
Development history backend (refactored from develop.c) |
253 / 1289 | - | - |
src/develop/imageop.c |
Pixel processing module API | 531 / 2264 | 617 / 2513 | 692 / 3181 |
src/control/jobs/control_jobs.c |
Background thread tasks | 315 / 1962 | 308 / 1904 | 394 / 2475 |
*: to this day, Darktable pixel pipeline cache is still broken as of 5.0, which clearly shows that increasing its complexity was not a solution:
| File | Description | Ansel Master | Darktable 4.0 | Darktable 5.0 |
|---|---|---|---|---|
src/bauhaus/bauhaus.c |
Custom Gtk widgets (sliders/comboboxes) for modules | 470 / 2344 | 653 / 2833 | 751 / 3317 |
src/gui/accelerators.c |
Key shortcuts handler | 88 / 342 | 1088 / 3546 | 1245 / 5221 |
src/views/darkroom.c |
Darkroom GUI view | 383 / 2101 | 736 / 3558 | 560 / 2776 |
src/libs/modulegroups.c |
Groups of modules in darkroom GUI | 149 / 608 | 554 / 3155 | 564 / 3322 |
src/views/lighttable.c |
Lighttable GUI view | 17 / 152 | 227 / 1002 | 237 / 1007 |
src/dtgtk/thumbtable.c |
Lighttable & filmroll grid of thumbnails view | 284 / 1261 | 533 / 2146 | 559 / 2657 |
src/dtgtk/thumbnail.c |
Lighttable & filmroll thumbnails | 157 / 924 | 345 / 1622 | 332 / 1841 |
src/libs/tools/filter.c |
Darktable 3.x Lighttable collection filters & sorting (original) | 82 / 607 | - | - |
src/libs/filters |
Darktable 4.x Lighttable collection filters (modules) | - | 453 / 2296 | 504 / 2664 |
src/libs/filtering.c |
Darktable 4.x Lighttable collection filters (main widget) | - | 245 / 1633 | 290 / 1842 |
src/common/import.c |
File import popup window | 130 / 915 | 309 / 1923 | 334 / 2309 |
