aurelienpierreeng/ansel

History module: Strange behavior with "activate/deactivate module" event

Closed this issue · 0 comments

Description of the bug

I have noticed that the history module adds new items on top of the current selected item in the list but there is a strange exception to this:

When you have an anterior item selected to go backward in the history:
if there is at least one deactivate or/and activate module item above the current position,
and if you do any change in the picture, then the new event is added from the top of the list and without deleting items above the current selected item.

This cause to reapply all the events above the current position because the current position change to the top of the list without deleting the unwanted items.

To Reproduce

  1. Edit a picture
  2. Deactivate at least one module near the end.
  3. Click on an item of the history list in the history module, that must be bellow a module deactivation item.
    image
  4. Note which number has been chosen.
  5. Do an edit.
  6. See the new item is added at the top line +1 and all items that were above the chosen item at step 3. have not been removed
    image
    (note: the item 19 color equalizer disappeared because that module was active once item 18 was selected)

Expected behavior

Anything above the current item should be removed before adding new history line.
image

Which commit introduced the error

The commit that now shows all the history items in the history module just been merged.
(a518023)

System

  • darktable version : a518023
  • OS : Win11 22H2
  • Memory : more than granny
  • Graphics card : Intel
  • Graphics driver : Intel
  • OpenCL installed : yes
  • OpenCL activated : yes
  • GTK+ : 3
  • gcc : yes
  • cflags : see build.sh
  • CMAKE_BUILD_TYPE : the one in build.sh

Additional context

  • Can you reproduce with another darktable version(s)? no
  • Can you reproduce with a RAW or Jpeg or both? both
  • Are the steps above reproducible with a fresh edit (i.e. after discarding history)? yes
  • Is the issue still present using an empty/new config-dir (e.g. start darktable with --configdir "/tmp")? yes
  • Do you use lua scripts? no