The current problem

Ansel is not modular, as the /src dependency graph shows: everything is wired to the GUI, "modules" are all aware of everything. Modifying anything somewhere typically breaks something unexpected somewhere else.

Target design

Note: because of the plotting library, this is a reversed dependency graph.

We should here make distinctions between:

libs : basic shared libraries, within the scope of the project, that do basic-enough reusable operation, unaware of app-wise datatypes and data (plotted with rounded corners).
modules (in the programming sense) : self-enclosed code units that cover high-level functionnality (plotted with square corners).

IOP modules

IOP (Image OPerations) modules are more like plugins: it's actually how they are referred to in many early files. They define both a pipeline node (aka pixel filtering code) and a GUI widget in darkroom. The early design shows initial intent of making them re-orderable in the pipelpine, and to allow third-party plugins. As such, the core was designed to be unaware of IOP internals.

As that initial project seemed to be abandonned, IOP modules became less and less enclosed from the core, which allowed some lazy mixes and confusions between what belongs to the scope of the pipeline, and what belongs to the scope of modules. The pipeline output profile can therefore be retrieved from the colorout module or from the pipeline data. color calibration reads the input profile from colorin.

IOP modules also commit their parameter history directly using `darktable.develop` global data, instead of using their private link `(dt_iop_module_t *)->dev`, which is documented in an old comment to be the only thread-safe way of doing it.

TODO:

[ ] make IOP modules only aware of history and GUI object,
[ ] handle uniform ways of communicating between modules on the pipeline

History

The editing history is the snapshot of parameters for each IOP. It gets saved to the database. It gets read and flattened to copy parameters to pipeline nodes. The problem of the history code, right now, is it was hacked with masks later, so it mixes SQL code, GUI code, pixelpipe code and… well, history code.

History should only deal with push/pop/merge operations and communicate with pipeline through a flattened associative list: 1 parameter state <-> 1 pipeline node.

Develop

The development is an hybrid thing joining history with pipeline. This object will take care of reading the image cache to grab the buffer, reading the database history, initing a pipeline, and starting a new computing job.

But again, it has been hacked to lazily handle in a centralized fashion many things that only belong to the darkroom, like the colorpicker proxies, overexposed/gamut alerts, ISO 12626 preview, and such. Those belong to GUI, because development objects are also used when exporting images or rendering thumbnails.