Summary: | when moving assigned tag in the keywords hierachy it becomes unassigned | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | terri.bugs |
Component: | Tags-Keywords | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles, marcel.wiesweg |
Priority: | NOR | ||
Version: | 1.2.0 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.2.0 | |
Sentry Crash Report: |
Description
terri.bugs
2010-02-12 11:51:45 UTC
Do you use drag & drop ? Gilles Caulier Marcel, I think this is a bug in the tag model, or what do you think? Yes, I use drag & drop. The problem is that model/view has no real idea of "moving". Therefore, when moving a tag, we first delete on the previous position and then add at the next position. Currently, the checkable model as well as the MetadataHub clear state in the signalAlbumAboutToBeDeleted. They should not if this is part of a move operation - in this case, the TAlbum* object and tag id is preserved. SVN commit 1091831 by mwiesweg: Provide information if an album is being moved. In this case, state can be preserved because the object will not be deleted. CCBUG: 226504 M +12 -1 albummanager.cpp M +15 -1 albummanager.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1091831 SVN commit 1091832 by mwiesweg: For the time being (until there is a thread-safe tag cache at a low level) we must look after the MetadataHub and notify it when tags are removed. This code was already added for 1.0, got lost during the model/view merge, but we got crash reports for 1.0-beta5, 1.0.0, 1.1.0, and 1.2.0-svn. So I cannot be sure that this fully fixes 214340. CCBUG: 226504 CCBUG: 214340 M +17 -0 imagedescedittab.cpp M +2 -0 imagedescedittab.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1091832 Should the above modifications have solved the problem of moving a tag in the hierarchy? Because tags still become unassigned in svn 1092129 if they are moved. Yes, they are supposed to fix this and they do it for me... Am I testing a different case? I take a picture, the tree view in the comments/tags tab on the right, and move assigned tags to a different parent. Yes, you seem to be testing the same case. However, it still doesn't work for me. Example, I have tags test/test2 and test3. I apply the tag test/test2 to an image and then move the tag test2 under test3. Result: test2 becomes unassigned. The hierarchy at the end is test, test3/test2. Also digikam doesn't seem to acknowledge the moving of a tag as a change that should be written to the file. If one moves a tag in the hierarchy the tick in the Apply -button remains grey (it doesn't change color to green). At least that happens with me. I confirm that moving a tag currently does not enable the "Apply" button. But the rest works for me. Perhaps, Johannes or Gilles, can you test this? uh-uh, sorry. I forgot to commit one important piece. SVN commit 1093300 by mwiesweg: Preserve check state if album is moved CCBUG: 226504 M +3 -1 abstractalbummodel.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1093300 Assuming it's fixed |