Summary: | Warning ("Another tag with the same name already exists") when merging several tags appears too soon | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | MarcP <iwannaberich> |
Component: | Tags-Keywords | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | caulier.gilles, iwannaberich, metzpinguin |
Priority: | NOR | ||
Version: | 7.4.0 | ||
Target Milestone: | --- | ||
Platform: | Flatpak | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/graphics/digikam/commit/bb5873182d190f592773d9f49eb6d99881a56307 | Version Fixed In: | 8.1.0 |
Sentry Crash Report: |
Description
MarcP
2022-01-10 17:39:09 UTC
The already running merge process will not be canceled. Only the new merge process that caused the dialog is not carried out. We would only have the option to block the GUI with the warning message and then continue when the current merge is finished. A kind of waiting buffer is not really feasible because the tag tree changes due to the ongoing processes. Maik Would it be possible to check if all the merges in a batch are non-conflicting (e.g. a future merge is referencing to a tag that has been deleted or merged in a previous merge), and only show one confirmation popup for all? The problem is not the merging of the tags in the database, this even takes place immediately and in the GUI thread and does not take any time. I remember that we introduced the warning dialog on the basis of a bug report from you, because you had other metadata writing processes running and then changed the tag tree, which leads to inconsenting image metadata. The warning dialog appears if a process is being executed in the Progress Manager at all, this could also be a copying process. Maik Mmm, I don't remember the exact context now, but I believe consistency in the database/metadata should be more important than user friendliness. In any case, the thing is that the user should not click on the next "Yes" until the changes on the previous picture have been applied, because the following file won't be processed then (and 99.9% of the times the user would want the changes to be applied). What could be a good strategy? Couldn't that popup be delayed until it's the next picture's turn somehow? Ok, it wasn't a bug report from you. ((:-)) Bug 406309 Maik No worries, it sounds like the kind of thing I would complain about : ) We are in the GUI thread with drag & drop. If we delayed it, nothing would happen during the drop, no message, no change in the tag tree ... nothing that would be particularly problematic. If we wait, we would block the GUI and nothing would be selectable anymore. Maik Maik, What the status of this file exactly ? Gilles Git commit bb5873182d190f592773d9f49eb6d99881a56307 by Maik Qualmann. Committed on 01/05/2023 at 20:19. Pushed by mqualmann into branch 'master'. remove progressmanager warning, since we are now cascading jobs FIXED-IN: 8.1.0 M +1 -1 NEWS M +0 -14 core/libs/album/manager/albummanager_talbum.cpp https://invent.kde.org/graphics/digikam/commit/bb5873182d190f592773d9f49eb6d99881a56307 |