Summary: | Revert and undo in image editor does not work | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Guenther M. Erhard <guenther-digikam> |
Component: | ImageEditor-Undo | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | marcel.wiesweg |
Priority: | NOR | ||
Version: | 1.0.0 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.0.0 |
Description
Guenther M. Erhard
2009-10-23 13:48:25 UTC
Not reproducible here.... Gilles Caulier Works fine here, too... (In reply to comment #2) > Works fine here, too... During my attempts to get assigning color profiles working again I upgraded now kde to 4.3.2 and qt to 4.5.2. On top of that I de-installed everything (hopefully) from svn, checked out and compiled again. Color profile is working now, but revert and undo still show this odd behaviour. :-(. I've tested it under kde3.5, kde4.3.2 and Gnome2.28: no difference. Guenther I can confirm a dysfunction in UNDO now, and it is very weird. I just discovered it for the first time, but my issue seems to be different. I opened a single file (an single image in a folder) and edited it. Then I pressed "undo", and a totally different file from a different folder (which is not loaded into IE at all) is displayed! I'll do a small video to proof it. (In reply to comment #5) > Here: http://digikam3rdparty.free.fr/misc.tarballs/temp/undo_broken.mov Very odd. That is different to my bug. I have gone now back from kde4.3.2 to kde4.2.4, because the crash at the program exit was distracting. Afterwards I have compiled a new version 1.0.0-beta6 (rev.: 1039950). At least for the moment undo is working now. It seems that it is somehow dependend on kde libraries and versions. Revert still does not show the original image after discard. Guenther What's the size of your image. What do you see on the console when you run digiKam (run kdebugdialog and turn on digikam debug space before) What the space on you /var. Usually, it's the place where temp files are written by editor (under Mandriva for me) Gilles Caulier According to "git bisect", commit #1014134 (http://websvn.kde.org/?revision=1014134&view=revision) is responsible for the "revert" issue. I guess my weird "undo" issue from the video link above (I can not reproduce it right now) might be introduced by this commit as well, since something about image loading changed? SVN commit 1040697 by mwiesweg: Fix "Revert" button in editor (calling resetValues() will clear the currentDescription) CCBUG: 211535 M +2 -2 dimginterface.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1040697 The "revert" problem is fixed, but I can't reproduce any undo/redo problem here. I think these problems are unrelated, because revert() works by full reloading while undo/redo replaces the image data of the current image, not using the loading framework. (In reply to comment #8) > What's the size of your image. > This independent of the size. I have images with a few 100k up to 120MB. > What do you see on the console when you run digiKam (run kdebugdialog and turn > on digikam debug space before) > There is no entry of digikam in kdebugdialog. On the console I see only this: digikam(11315)/digikam (core) Digikam::DImg::load: "" : Unknown image format !!! digikam(11315)/digikam (core) Digikam::DImgInterface::getImg: d->image is NULL > What the space on you /var. Usually, it's the place where temp files are > written by editor (under Mandriva for me) > 18GB left - should be enough. Guenther (In reply to comment #12) > The "revert" problem is fixed, but I can't reproduce any undo/redo problem > here. > I think these problems are unrelated, because revert() works by full reloading > while undo/redo replaces the image data of the current image, not using the > loading framework. > I can confirm that with version 1.0.0-beta6 (rev.: 1040748) revert as well as undo is now working without problems. Thanks for the quick fix. Guenther So, we can close this file now ? Gilles Caulier (In reply to comment #15) > So, we can close this file now ? > From my point of view: yes. Guenther |