Adds per-duplicate duplicate/original buttons to the duplicate manager.

[masterpiga]

Fixes #21353.

Incidentally, also fixes a pre-existing leak in the row loop: gtk_label_new(g_strdup(chl)) -> gtk_label_new(chl) (the label copies its argument; the g_strdup leaked on every rebuild).

Screen.Recording.2026-06-22.at.21.37.09.mp4

[masterpiga]

@leonidas111 @TurboGit

[masterpiga]

Minor update:

1. Added some spacing to the left of the "delete" button, for better separation
2. Added individual classes to style the three buttons independently
3. The "duplicate with history" only shows for images that have been developed (as the two actions are otherwise equivalent)

[wpferguson]

@masterpiga how do you handle the grouping? Everything is grouped with the "original" original or is the duplicate grouped with the parent if the parent is not the original?

I tested and I have a thought (I know.... 😄). Let's say I edit the original, and then create a duplicate (1) with history stack. Then I edit 1 and want to keep it. But I also have another direction to take 1, so I want to duplicate the original 1, not the original 0. I tried that and got the original 0 duplicated. To me when I pick original on duplicate 1 if it's going to give me duplicate of original 0 then it's a useless button. If I wanted a duplicate of original 0 then I would go to 0 and hit the original button.

I also wonder how we are going to keep track of what's the parent of what. Maybe some kind of darktable based tagging (darktable|duplicate|<parent filename>|<child filename>|<version?>

EDIT: We could do 2 things to keep track of the duplicate relationships, filename and version number. Filename would have appended _01, _02, etc for direct descendants and _01, _01_01, _01_02, _02, _03, _03_01 for descendants of descendants. The version number could be a string instead of a number and then we could have 1, 1.1, 1.1.1, 1.1.2, in other words each generation getting another decimal point.

EDIT 2: Does this make your head hurt 🤣

[masterpiga]

Thanks for your feedback, Will!

how do you handle the grouping? Everything is grouped with the "original" original or is the duplicate grouped with the parent if the parent is not the original?

I didn't change how grouping is handled, it works just like before.

so I want to duplicate the original 1, not the original 0

I am not following, there is only one original, i.e., the raw file with no edits. This change only changes the UI, it does not alter the logic of how duplicates work.

when I pick original on duplicate 1 if it's going to give me duplicate of original 0 then it's a useless button.

It's what the original button used to do also before this change. The only difference is that before "original" would always take the original of the currently developed image. Whereas now it takes the original of whatever row's button you click. The image will be identical. Tags and other metadata are copied from the selected image. Concretely this is the same behavior as before, only that now you don't have to open an image in the darkroom to create a duplicate or a virgin copy.

I also wonder how we are going to keep track of what's the parent of what. Maybe some kind of darktable based tagging (darktable|duplicate|||<version?>

EDIT: We could do 2 things to keep track of the duplicate relationships, filename and version number. Filename would have appended _01, _02, etc for direct descendants and _01, _01_01, _01_02, _02, _03, _03_01 for descendants of descendants. The version number could be a string instead of a number and then we could have 1, 1.1, 1.1.1, 1.1.2, in other words each generation getting another decimal point.

I think this is all tangent and unrelated. This change is basically a no-op functionality wise, it is just a very focused UX improvement.

EDIT 2: Does this make your head hurt 🤣

Just a bit 😅! It's smelting hot here, my head was hurting already before 😭

[wpferguson]

I took a negative image, so that's the original.
I cropped it (0) and duplicated so that's the next one
I used negadoctor to crate a positive (1) and duplicated
I used agx to raise the exposure (2). Then I click original from (2) and I got (3) the uncropped negative that is the true original, but the original of (2) should be (1).

Does that make sense?

EDIT: Also, any idea why the 3 is offset?

EDIT 2: There are less icons

[masterpiga]

Does that make sense?

I don't know 😂 I don't understand if there is a regression, or you are just describing how you think that it should work. If you do the same steps with the current duplicate manager do you get a different result? That shouldn't be the case. I am not changing any behavior here, the change should be purely cosmetic.

This is the duplicate manager at head. If I:

• edit (0)
• duplicate it into (1)
• duplicate "original" (1) into (2)

I get exactly the same as (0) before my edits, i.e., the image with no edits. IIUC, this is exactly what you get with the change, which is WAI.

Screen.Recording.2026-06-23.at.20.17.15.mp4

EDIT: Also, any idea why the 3 is offset?

EDIT 2: There are less icons

Nice catch, thanks. That needs fixing.

[wpferguson]

You are right, the behavior is the same, but having the original icon on each image implies, to me at least, that I will get the image that it's descended from, not the original original. If you are only ever going to get the original original, then, IMO, there should only be one button.

I can live with it, but I do think users are going to be confused.

[masterpiga]

I can live with it, but I do think users are going to be confused.

Eh! This was my first response when the feature was originally proposed:

The only thing that I do not love is that the “duplicate (original)” action is the same regardless of which duplicate you start from - i.e., it’s a function of the photo, not of one specific duplicate. So, having the button repeated for each duplicate can be a bit confusing.

OTOH the tooltips are clear, so hopefully that will help clear the doubts.

I still think it's a net win, because (1) one does not need to develop an image before it can be duplicated, and (2) the UI real estate is used more efficiently.