| Summary: | "Recent Tags" menu show existing tags added and shouldn't be | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | julien.t43+kde |
| Component: | Usability-Menus | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ajg02, caulier.gilles |
| Priority: | NOR | ||
| Version: | 7.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/kde/digikam/commit/cc49e11dbf8a89ecf1299187e837bf87039b82da | Version Fixed In: | 7.0.0 |
|
Description
julien.t43+kde
2012-11-05 17:12:51 UTC
I remember that something like that have been fixed recently. Can you try with 2.9.0 release ? Gilles Caulier I am seeing this on 2.9.0 I would if I can, but for now, Philipp seems to not have time to update his ppa (https://launchpad.net/~philip5/+archive/extra) and not really wanted to do full manual compile, so waiting for now. From which UI element do you add the new tag? The way it is currently implemented, we update the recent-tags list when a tag is assigned, but the assignment does not check ( and will not, for reason of performance) if the tag is already assigned. for now, I'm using mostly the right panel or context menu/recent tags if tags is listed there either in thumbnail or preview mode. Can't use keyboard shortcuts as I have too many tags (outside of a few). But I think it happens in the 3 cases. For performance, for sure, it's an extra task but on current desktop, I don't think the penalty is noticeable (especially if you cache displayed data). On a laptop (and especially my netbook), probably heavier. Marcel, I think you miss the point. When you assign a new tag to an image, all tags for that image are added to the recently used list, even if they are not being changed in this operation. This is wrong. Only the tag actually added should go into the recently used list. This is using the right hand side bar. eg if an image previously had tags a,b,c,d,e,f,g,h,i,j assigned and then you assign tag k, then all those tags go into the recently used list. Apparently all existing tags are assigned (a no-op for already assigned ones), resulting in the observed behavior. The underlying problem is that the list is kept at a very low level. I believe it should be kept more high-level in TagsCache and co-managed through ImageInfo. Then the cost I mentioned is gone, due to caching. still valid Test on 3.4 (lubuntu 13.10/kde 4.11.3 main install). pending on 3.5(macos 10.9/kde 4.11.4/macports, mostly w network share)(long collection scanning...) Julien, This file still valid using last digiKam 4.2.0 ? Gilles Caulier This file still valid using last digiKam 4.10.0 ? Gilles Caulier New digiKam 4.11.0 is available with official PKG installer for OSX. https://www.digikam.org/node/740 Can you reproduce the problem with this release ? Gilles Caulier digiKam 4.12.0 is out : https://www.digikam.org/node/741 We need a fresh feedback using this release please... Thanks in advance. Gilles Caulier With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier Just tested on 7.0.0 beta, the problem is still here. Git commit cc49e11dbf8a89ecf1299187e837bf87039b82da by Maik Qualmann. Committed on 28/04/2020 at 19:52. Pushed by mqualmann into branch 'master'. fix recently tags list FIXED-IN: 7.0.0 M +2 -1 NEWS M +15 -4 core/libs/database/coredb/coredb.cpp https://invent.kde.org/kde/digikam/commit/cc49e11dbf8a89ecf1299187e837bf87039b82da Git commit 728c49ce1a4ecc935cf1ac2a6d96233ebb899828 by Maik Qualmann. Committed on 29/04/2020 at 06:02. Pushed by mqualmann into branch 'master'. use ItemInfo cache for a better performance M +5 -14 core/libs/database/coredb/coredb.cpp M +2 -1 core/libs/database/coredb/coredb.h M +2 -1 core/libs/database/item/containers/iteminfo_tags.cpp https://invent.kde.org/kde/digikam/commit/728c49ce1a4ecc935cf1ac2a6d96233ebb899828 |