Bug 432568 - Provisional tags are not displayed until another change is made
Summary: Provisional tags are not displayed until another change is made
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Tags-Keywords (show other bugs)
Version: 7.2.0
Platform: Flatpak Linux
: NOR minor
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-02-06 11:54 UTC by MarcP
Modified: 2021-02-07 13:05 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.2.0
Sentry Crash Report:


Attachments
Normal behavior with first-level tags. No problem here. (1.81 MB, image/gif)
2021-02-06 12:56 UTC, MarcP
Details
Weird behavior when tag trees are involved (1.28 MB, image/gif)
2021-02-06 12:57 UTC, MarcP
Details

Note You need to log in before you can comment on or make changes to this bug.
Description MarcP 2021-02-06 11:54:23 UTC
SUMMARY

Sorry if the title is not very clear. This is most likely related to Bug 431354.

I usually tag my nature photographies using a tag tree that shows their taxonomy. That implies a tag tree with four or five levels. For every picture, I need to add three or four tags, and then drag an drop them on top of each other to create a hierarchy.

The issue is that when I add a tag (Using the Captions/Tags panel), the recently added tag does not appear until a second tag is added, or a tag has been moved in the hierarchy.

For instance, Let's say that you want to tag a picture of a dog with the following tag tree: Animal/Mammal/Dog. First, you type Animal and create the tag (nothing will appear at this point on the list), then you type Mammal (at this point, "Animal" will appear), and finally you type Dog (now "Mammal" will appear). If you make any other change to the current tags, like drag and drop Mammal inside Animal, "Dog" will also appear.

To sum up, changes are not refreshed until a subsequent action is done on those tagg.

STEPS TO REPRODUCE
1. Select new picture and to go the Captions/Tag panel.
2. Enter one keyword and create it
3. Enter a second keyword and create it

OBSERVED RESULT
Only the first keyword is visible at this point.

EXPECTED RESULT
Both tags should be visible at this point. They should be visible immediately after adding them.

SOFTWARE/OS VERSIONS

Linux/KDE Plasma: Ubuntu 20.04 with Gnome, with digikam 7.2.0-rc Build date: 6/2/21 10:28 (target: Debug) Rev.: 7d4eb6c5940a08523607c1378fe9b931d2796d58 (from flatpak)

ADDITIONAL INFORMATION

This is all before hitting the Apply button.
Comment 1 Maik Qualmann 2021-02-06 12:03:10 UTC
I cannot reproduce that and have never observed it. The tag appears immediately in the tags list. When a tag is created in the database, an event is sent to the Tag list models. The only explanation is that writing into the SQLite database takes a long time for you. Can this also be reproduced with the AppImage or only with the flatpack?

Maik
Comment 2 MarcP 2021-02-06 12:56:14 UTC
Ok, I have just tried with an appimage version of digikam (7.1 stable release), and the behavior is also there. But I realised something. This only occurs when the picture already has tags in form of a tree.

So for instance. A pictures with just first-level tags, the new tags will appear immediately, no problem there. But as soon as hierarchical tags are involved, that weird behavior will appear. I have made two screen captures comparing the difference.

One thing I forgot to mention was that I leave the "Tag already assigned" button on, since I have thousands of tags and otherwise it would be impossible to add keywords to pictures.
Comment 3 MarcP 2021-02-06 12:56:42 UTC
Created attachment 135462 [details]
Normal behavior with first-level tags. No problem here.
Comment 4 MarcP 2021-02-06 12:57:10 UTC
Created attachment 135463 [details]
Weird behavior when tag trees are involved
Comment 5 Maik Qualmann 2021-02-06 14:15:07 UTC
Marc, you have a filtered tags view. If I fix the problem and update the filter after adding a tag, no new tag will be visible at all. The tags are not yet assigned to the image, the new tags should not appear at all, this is the intent of the filter, which should only display tags that are assigned to the image.

Maik
Comment 6 MarcP 2021-02-06 14:38:00 UTC
Yes, I know, but even considering that, there's something weird the way it works now (that also applies for Bug 431354, as it's likely the same thing).

So, when you tag an image, the new tags you see in that panel have not yet written to the file, so even if the "Tags already assigned" filter is off, these tags should not appear. But they do. And only if they are not hierarchical. That's what I am reporting in this bug. Oh, and by the way, I realized that if you click and unclick the "tags already assigned" button, all tags appear at a given moment, so it's a workaround. Couldn't we force a "refresh" like that when each tag is added?

In any case, I think the ideal behavior should be like this:

You tag a picture, these keywords should already appear in the tag panel, but "pre-assigned" in a different color, as they won't be written until you hit apply. (that's already the case for reverse geotagging, where pre-assigned tags appear in green before being written). Then you hit "Apply", the new keywords are written to the file and appear in the default color just like any other tag.

I don't know if you follow me, it can be a bit abstract at times...
Comment 7 Maik Qualmann 2021-02-06 18:23:05 UTC
Git commit e50d6bffc51212fa56016a6a83b9bdcd62dd49ed by Maik Qualmann.
Committed on 06/02/2021 at 18:21.
Pushed by mqualmann into branch 'master'.

show new assigned tags in the filtered tags view
Related: bug 431354
FIXED-IN: 7.2.0

M  +3    -1    NEWS
M  +8    -0    core/libs/models/albumfiltermodel.cpp
M  +5    -0    core/libs/models/albumfiltermodel.h
M  +1    -0    core/libs/properties/captions/itemdescedittab.cpp
M  +5    -0    core/libs/tags/widgets/tagcheckview.cpp

https://invent.kde.org/graphics/digikam/commit/e50d6bffc51212fa56016a6a83b9bdcd62dd49ed
Comment 8 Maik Qualmann 2021-02-06 18:27:51 UTC
I can always follow your explanations very well...((:-))

Maik
Comment 9 MarcP 2021-02-07 13:05:28 UTC
Works perfectly. Thank you Maik, you are the best!