Project

General

Profile

Feature #8620

Feature #8769: Remove "Snapshot" module and integrate its functionality into the stack

History stack should'n compress stack after next/prev picture

Added by ungift-ed - over 6 years ago. Updated over 3 years ago.

Status:
Fixed
Priority:
Medium
Category:
-
Start date:
Due date:
% Done:

100%

Affected Version:
System:
bitness:
hardware architecture:
amd64/x86

Description

Yesterday, I did test darktable 1.0rc2
On some photo I show original to my wife and the I show prev picture.
Whan I back all my changes was lost and I have only original picture.

IMHO dt should compress history stack only when I use some new tool or when I press compress button.

Steps:
1. Open picture
2. Edit it. Use many tools.
3. On history stack tool select original
4. Switch to another picture
5. You lost everything made in prev picture :(


Related issues

Duplicated by darktable - Bug #10115: History loss Duplicate 09/20/2014
Duplicated by darktable - Bug #10441: Switching to lighttable from darkroom should never lost part of history Fixed 04/29/2015

Associated revisions

Revision a237fa1f
Added by Tobias Ellinghaus over 3 years ago

Preserve history above selected when leaving dr

Fix #8620.
Fix #10441.
This needs some testing, especially with styles and the Lightroom stuff.

History

#1 Updated by mimoklepes - over 6 years ago

I would like to support this idea. Whenever anything else than the latest level is selected in the history stack, DT should probably ask for confirmation when it's about to throw away the remaining history (when switching to another image, back to lighttable, maybe even after pressing the compress history button). This confirmation might be configurable, similar to deleting tags etc.

#2 Updated by Henrik Andersson over 6 years ago

I have been having this issue a loong time, i hate it that history stack is
destroyed in background without notification, i have been burnt by this "feature"
many times loosing the processing of images.

I had a loong discussion about removing this with Johannes, and we couldnt agree,
so we postponed the discussion.

#3 Updated by ungift-ed - over 6 years ago

For it not problem to know: I always lost any history on top of current selection in history stack.
I alays keep it in mind and I hate a lot of questions like "are you sure?".

For me really BUG (and this ticket about) is: darktable SHOULDN'T compress history when I switch to prev/next picture.

ps. may be sometime dt should implement some undo feature.
pps. please excuse my engrish :)

#4 Updated by mimoklepes - over 6 years ago

I consider it a good user interface design when you need to confirm any destructive non-undoable action. Especially in a GUI like darktable with small buttons, where "compress stack" is only few pixels away from "create a style", user can unintentionally click the other one.

Anyway I agree that the act of throwing away the stack when switching images is the main concern.

#5 Updated by Simon Spannagel over 6 years ago

Hm, maybe it would be nice to get an agreement for 1.0.1?
I set the version to this...

#6 Updated by Simon Spannagel over 6 years ago

  • Target version changed from 1.0.3 to Candidate for next patch release

#7 Updated by Simon Spannagel over 6 years ago

  • Status changed from New to Triaged
  • Affected Version set to git development version
  • Parent task set to #8769
  • % Done changed from 0 to 20
  • Target version changed from Candidate for next patch release to Candidate for next major release
  • Priority changed from High to Medium

okay, maybe this should be solved within another task - the merging of snapshots and history module.

#8 Updated by Simon Spannagel over 5 years ago

  • Tracker changed from Bug to Feature

#9 Updated by Antoine Beaupré over 5 years ago

there was a conversation on IRC regarding this problem, and it seems the agreement is that a short term solution for this problem would be to simply store the index of the current in the database (and the xmp) as opposed to rendering it and compressing the history. that way, selecting the version would stick around when changing the view while further history would be kept.

#10 Updated by Jose Carlos Garcia Sogo over 5 years ago

  • Assignee set to Jose Carlos Garcia Sogo

#11 Updated by Jose Carlos Garcia Sogo over 5 years ago

<note to self> this implies adding a new column to history table in the db that stores the num (of the history stack) that the user has chosen to point at, so we can retrieve it even after closing darktable. This should also be synced to the xmp file, by adding a new tag.

Still, the user will lose the history above this point if he makes any edit when the history step selected is not the top one.

#12 Updated by Tobias Ellinghaus over 5 years ago

Jose Carlos Garcia Sogo wrote:

<note to self> this implies adding a new column to history table in the db that stores the num (of the history stack) that the user has chosen to point at, so we can retrieve it even after closing darktable. This should also be synced to the xmp file, by adding a new tag.

No, the extra column has to be in the images table, not in history!

Still, the user will lose the history above this point if he makes any edit when the history step selected is not the top one.

That's intended behaviour and shouldn't change. I don't know any program where going back in the history and doing changes doesn't kill what has been undone.

#13 Updated by Federico Bruni over 4 years ago

I have a similar problem, but I'm not sure if it can be included in this issue.
If I select a previous step of history stack (to see how it looked like) and then I start editing, the last steps of development (on top) are automatically removed without any warning. Is it intended?

#14 Updated by Tobias Ellinghaus over 4 years ago

Yes, that is intended. Selecting anything but the top entry of the history stack is like undoing actions in other programs. If you continue working from such a state you can't redo them any more.

#16 Updated by Roman Lebedev about 4 years ago

#17 Updated by Roman Lebedev over 3 years ago

  • Duplicated by Bug #10441: Switching to lighttable from darkroom should never lost part of history added

#18 Updated by Tobias Ellinghaus over 3 years ago

  • % Done changed from 20 to 100
  • Status changed from Triaged to Fixed

Also available in: Atom PDF