[digikam] [Bug 402288] The default Xmp.lr.hierarchicalSubject setting does not read darktable tags
https://bugs.kde.org/show_bug.cgi?id=402288 --- Comment #9 from Daniel Laidig --- I did some digging and at least in 2010, Gilles did... ;) See bug 221460 comment 12. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 402288] The default Xmp.lr.hierarchicalSubject setting does not read darktable tags
https://bugs.kde.org/show_bug.cgi?id=402288 --- Comment #5 from Daniel Laidig --- I was testing with the 6.2.0 Appimage. Thanks for the info that I can add the same namespace multiple times. This is certainly an improvement for my current setup. :) When looking at the default config for Xmp.lr.hierarchicalSubject, I noticed that Xmp.lr.hierarchicalSubject is set to TAG_XMPBAG and the alternative name is Xmp.lr.HierarchicalSubject (capitalized) as TAG_XMPSEQ. From what I understand now, this looks digikam always write the non-capitalized version only (as Bag) and if not found during reading, it will try to read the capitalized version as Seq only. Considering that you wrote in comment 1 that you use the "capitalized alternative Xmp.lr.HierarchicalSubject as Seq" (which seems not the current behavior any more), doesn't that mean there is another issue and digikam might not be able to read tags from its own sidecars from older versions any more? In any case, while I very much appreciate your comments that help me configure digikam to be usable for my workflow, I would be very happy if out-of-the-box compatibility between digikam and other applications is as high as possible. I guess this would either mean making the reading more fault tolerant or adding another default entry. Is as good as possible out-of-the-box compatibility with darktable and other applications also something you are aiming for or is this something where I should just tune my config? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 402288] The default Xmp.lr.hierarchicalSubject setting does not read darktable tags
https://bugs.kde.org/show_bug.cgi?id=402288 Daniel Laidig changed: What|Removed |Added CC||lai...@kde.org --- Comment #3 from Daniel Laidig --- I stumbled across the same issue yesterday. In an effort to achieve compatibility between digikam and darktable, I used Settings > Metadata > Advanced to only enable Xmp.lr.hierarchicalSubject for tags, only to then find out that my tags are deleted by a digikam->darktable->digikam roundtrip. Then I tried the workaround suggested by you, Maik, i.e. creating a new entry that is a duplicate of Xmp.lr.hierarchicalSubject but with TAG_XMPSEQ instead of TAG_XMPBAG and enabling only that one. That seems to make the roundtrip work, but I guess you might lose tags now if they are stored in a standard-compliant way. What darktable does, btw, is to accept both Bag and Seq when reading xmp sidecars but then to always write the sidecar back using a Seq. Wouldn't this be an option for digikam as well (reading both, saving as Bag)? I see that the functions MetaEngine::getXmpTagStringSeq and MetaEngine::getXmpTagStringBag are almost identical. Why not change them so they try to find the specified item (Bag or Seq) first but if this not found and there is only the other type, this one is read instead? I don't have experience to judge if there would be unintended side effects. But regardless of what is conforming to the standard, I think compatibility and avoid data loss is more important. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 410980] Sorting of albums in tree view by name inconsistent with Dolphin
https://bugs.kde.org/show_bug.cgi?id=410980 --- Comment #5 from Daniel Laidig --- Thanks for your amazingly fast reaction! :) I can verify that this is indeed a locale issue, but the behavior of your workaround is not exactly the same. On the two systems I tested (Fedora 30, Kubuntu 19.04), setting LANG=C changes the sort order to --- 2019 General 2019-01-01 New Year 2019-07 Summer vacation 2019-07-30 Some other album Stuff _Important_Top_Album --- i.e. the date-based names are sorted correctly while the sorting of the underscore is different. In Dolphin and with digikam from the distribution packages (6.1.0 on Fedora, 5.9.0 on Kubuntu), "_Important_Top_Album" is always the top entry. Starting the Appimage with LANG=C gives a "Your locale has changed since this album was last opened." warning. Therefore, wouldn't the following be a better workaround? LANG=C.UTF-8 ./digikam-6.2.0-x86-64.appimage For me, this workaround is good enough. Let me know if I can help, for example with testing a fixed Appimage. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 410980] New: Sorting of albums in tree view by name inconsistent with Dolphin
https://bugs.kde.org/show_bug.cgi?id=410980 Bug ID: 410980 Summary: Sorting of albums in tree view by name inconsistent with Dolphin Product: digikam Version: 6.2.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-TreeView Assignee: digikam-bugs-n...@kde.org Reporter: lai...@kde.org Target Milestone: --- SUMMARY The sorting behavior of albums by name in the tree view used to be consistent with other applications, especially Dolphin, meaning that special characters are not ignored (verified by running 5.9.0). This behavior seems to have changed recently. Personally, this breaks my workflow as I use a folder structure with underscores to ensure some items appear at the top and "", "-mm", "-mm-dd" prefixes for names (see an example below). Considering https://xkcd.com/1172/, I agree that this is not a valid argument, but I would argue that being consistent with Dolphin would be a good reason to revert to the old way. STEPS TO REPRODUCE 1. Create the following directories inside a subdirectory of the collection: --- _Important_Top_Album 2019 General 2019-01-01 New Year 2019-07 Summer vacation 2019-07-30 Some other album Stuff --- 2. In digikam, choose View -> Sort Items -> By Folder OBSERVED RESULT In the album tree view in digikam, the albums are sorted in the following order: (6.2.0 Appimage) --- 2019-01-01 New Year 2019-07-30 Some other album 2019-07 Summer vacation 2019 General _Important_Top_Album Stuff --- EXPECTED RESULT The albums should be sorted in the order of creation (underscore first, space before hyphen). This is the behavior found in Dolphin (and digikam 5.9.0). SOFTWARE/OS VERSION KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.2 ADDITIONAL INFORMATION After some grepping, I thought that AlbumFilterModel::lessThan() in core/libs/models/albumfiltermodel.cpp should be the relevant piece of code. However, this function has not changed between 5.9.0 and master, so I'm guessing that there has been some other kind of refactoring or that I am looking in the wrong place. Unfortunately, I do not have time to set up a development environment right now. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 400712] New: file modification timestamp is updated when images are moved to collection on removable media
https://bugs.kde.org/show_bug.cgi?id=400712 Bug ID: 400712 Summary: file modification timestamp is updated when images are moved to collection on removable media Product: digikam Version: 6.0.0 Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Database-Files Assignee: digikam-bugs-n...@kde.org Reporter: lai...@kde.org Target Milestone: --- SUMMARY When moving images from a local collection to a collection on removable media, the modification time (mtime) of the file is changed to the current time. This does not happen when moving files within a collection or between two local collections. STEPS TO REPRODUCE 1. Create a local collection and a collection on a removable media. 2. Add images to the local collection. 3. Move some images from the local collection to the collection on the removable media. OBSERVED RESULT The timestamp of the moved file is set to the current time. EXPECTED RESULT The timestamp should not change when moving files. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.13.5 KDE Frameworks Version: 5.50.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION I have observed this behavior with 5.9.0 and actually lost data (images from old digital cameras without metadata where the mtime was the only hint of the recording date). Just now, I reproduced it with the 6.0.0-beta2 appimage on a different machine. The "update file timestamp when files are modified" option does not seem to influence the described behavior. Not sure if it is relevant, but I have configured digikam to only write metadata to sidecar files. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398331] xmp sidecar files are not reloaded on change
https://bugs.kde.org/show_bug.cgi?id=398331 --- Comment #2 from Daniel Laidig --- Sorry, I tried to search for duplicates, but apparently not using the right terms. Is there are reason you didn't mark this bug as a duplicate? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 398331] New: xmp sidecar files are not reloaded on change
https://bugs.kde.org/show_bug.cgi?id=398331 Bug ID: 398331 Summary: xmp sidecar files are not reloaded on change Product: digikam Version: 6.0.0 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Metadata-Engine Assignee: digikam-bugs-n...@kde.org Reporter: lai...@kde.org Target Milestone: --- I set up digikam to write metadata only to xmp sidecar files and also checked "Rescan file when files are modified". However, changes in xmp sidecar files are not detected (not when digiKam is running and also not when restarting it). Reloading metadata works when the actual image is changed: exiv2 -M"set Xmp.xmp.Rating 3" IMG.JPG -> Rating is instantly updated in digiKam. When setting a rating in digikam and then using a text editor to change xmp:Rating in the xmp sidecar, the rating is not updated automatically. When triggering "Reread Metadata From File" manually or running "touch IMG.JPG", the rating is updated. Due to the last observation I would guess that the mtime of the xmp file is currently not stored in the database. Fixing this would make interoperability with other applications so much better. (tested using the 6.0.0-beta1 AppImage, but also previously observed with 5.9.0) -- You are receiving this mail because: You are watching all bug changes.
