Version: 2.1.0 (using KDE 4.7.0) OS: Linux Whichever point of edit step redo I select, it reverts step by step with the ultimate result being same as discard changes. Reproducible: Always Steps to Reproduce: as descibed Actual Results: as described Expected Results: As digikam editor is aware of which step at a certain point can be reverted, it would be nice if this was reflected in the menu, by graying out steps that are not available or group all steps that will be involved in a reversion to the selected point and do this steps at once, so not doing something you did not expect, no matter how logical explainable digikams action is, it is different from choosed.
I understand that you pick an item from the submenu (downwards arrow of the redo toolbar button) but as a result all available steps are redone? Undo (backwards) or redo (undo undone step)?
Rinnus, Can you reproduce the problem with current implementation from Git/Master (next 2.4.0) ? Gilles Caulier
On DigiKam 2.3.0, after applying the effect, the Redo button is disabled. I think the user may have meant Undo. After applying, if I Undo, I get back the image prior to applying the full effect i.e if i choose blur, try out blur at different settings and apply, I get the unblurred image and not one of the "set blur where I hadn't clicked OK yet". In Photoshop, I can Undo every small change like a blur but we use the mouse there and it has a different interface.
Rinus, This file still valid using digiKam 2.4 ? Gilles Caulier
Git commit fec6928e7e1b2300ae9c667503843162842e44c1 by Marcel Wiesweg. Committed on 21/02/2012 at 19:47. Pushed by mwiesweg into branch 'master'. Fix order of redo actions. Functionality was correct, but labelling was reversed. M +6 -2 utilities/imageeditor/canvas/undomanager.cpp http://commits.kde.org/digikam/fec6928e7e1b2300ae9c667503843162842e44c1
Undo/redo works fine for me. I have fixed a little problem with a reverse labelling of redo steps. No further input here from original reporter, so closing.
Git commit 19d4c9201ccd175ed67cee0724413e087fb4b0e2 by Francesco Riosa. Committed on 21/02/2012 at 21:40. Pushed by riosa into branch 'master'. [lcms2] tag buffer need initialization M +4 -1 libs/dklcms/digikam-lcms.cpp http://commits.kde.org/digikam/19d4c9201ccd175ed67cee0724413e087fb4b0e2
Git commit 326c8803e3740dfbd421a537b6226c2a25bd4426 by Francesco Riosa. Committed on 22/02/2012 at 00:22. Pushed by riosa into branch 'master'. [lcms2] fixed a cast bug in cmsFloat2XYZEncoded() We are now at feature parity with lcms1. There are differences between the two implementations, they are quantifiable even in 8bit images. lcms2 should be more precise (and faster) than lcms1 M +1 -7 libs/dklcms/digikam-lcms.cpp M +0 -3 libs/dklcms/digikam-lcms.h http://commits.kde.org/digikam/326c8803e3740dfbd421a537b6226c2a25bd4426
latest two comment obviously on the wrong bug :-/