When I open the Crop and Rotate module, do a rotation, then do a crop (or reverse the order), the history has 2 entries but compressing the history merges the 2 entries. This is good as it has evaluated all the “versions” of the module and combined them into 1.
However, when I open a module, make a change, go to another module make a change, go back to the first module and turn it off, then compress the history, the off module still appears in the history. If this is the last instance of that module, then the off version should not be there.
My feature request is that, if the Off version of a module is the last version of that module, then the module shouldn’t be listed in the compressed history (I don’t mind it appearing in the uncompressed history but I don’t think it should be present in compressed history.)
However, when I open a module, make a change, go to another module make a change, go back to the first module and turn it off, then compress the history, the off module still appears in the history. If this is the last instance of that module, then the off version should not be there.
Yes it should be there. Because some modules are enabled by default, if we delete the entry that says “users disabled that module on purpose”, darktable will re-enable the on-by-default modules next time you open the picture.
So we could have special rules that check the default status of each module when compressing history. But special rules × 77 modules are guaranteed to fail sometimes and trigger a lot of corner cases.
PS: I’m the author of a commit that did exactly what you ask. We had to revert it because it simply doesn’t work.
If you want to remove an “off” module from your history, enable it and then disable it again (to put it at the top of your history), compress once (now there’s just a single disabled copy of the module at the top of your history), select the module below the one you wish to remove, and compress again.
Especially when you’re using some performance consuming modules like denoise profiled it’s helpful being able to disable them after setting their parameters early in the workflow without losing these while heavy editing and compressing steps tidying the pipe. And then reactivate them in a last step without needing to reset their parameters and wait for a more time consuming processing.
Indeed. I have a bunch of presets that I auto-apply to all new edits in their “off” state so that I can selectively switch them on when required. These days my workflow is mostly deciding what switches to toggle.