Created attachment 105344 [details] Introduce additional sidecar types and fix bug in mime setup We already consider *.xmp files when renaming/moving/copying/... files, but some programs use custom extension for their metadata. To be honest, I only know of Rawtherapee's *.pp3 but that is reason enough. Therefore I introduced an additional field to the mime setup page for sidecar extensions. In contrast to the others, these files won't be registered in the database, but considered when doing IO operations. In the process I found an inconsistency that can lead to erroneous behaviour: In the GUI the user is told to use spaces to separate the extensions. The parsing function accepts either semicolons or spaces, but not both. The function that populates the input fields with existing extension inserts them with semicolons. So if you add a new extension ("ex1;ex2" -> "ex1;ex2 ex3") it won't be registered as a new extension but as a modification: "ex2" -> "ex2 ex3". As extensions can't (well shouldn't) contain spaces, I changed the parsing function to separate on both semicolons and spaces and adapted the explanation in the GUI. Also I changed to icons such that all mime icons are colored (not monochrome) according to the breeze-icons guidelines. As an aside: During renames this causes obviously failing thumbnail lookups for the sidecar files (was already the case for *.xmp). This is already addressed in my other patch about renaming.
Created attachment 105345 [details] Introduce additional sidecar types and fix bug in mime setup - 2
Simon, the way to host sidecar mime with Setup Type Mime is not the right one. The Setup Type Mime is to register mime of items committed in DB. It's not the case of sidecar files. There are parsed by metadata engine if Setup Metadata option is turned on. I recommend to move sidecar type mime in Setup Metadata panel. The way to handle sidecar in located in libs/dmetadata. In fact it's done internally by Exiv2, as i remember, but i'm not sure to 100%. At least check meta engine code about read and write from/to files. Gilles
My patch does not touch how metadata is handled and I don't intend to. This is only for file operations, i.e. dio.cpp. There currently on any operation it is checked whether a *.xmp file is present (via DMetadata::hasSidecar and DMetadata::hasSidecar). I extended this check to include the manually provided extensions. I will move out the part of the patch that fixes the bug in the mime setup to another issue and move this setting to metadata setup. However I am not quite sure where to place it. It is separate from all the metadata settings, as it does not concern handling metadata within digiKam. So maybe add a new tab even though it is just one setting?
Hi Simon, yes a new tab in Metadata panel will be fine to host this kind of settings. In fact i will see a dedicated tab for all sidecar settings. There are many entries in bugzilla about sidecars management. So, in "Behavior" tab, moving : - Read from sidecar files - Write from sidecar files + combo options ... To the new "Sidecar Files" tab will be logic. I recommend to put a tip label in "Reading and Writing" group-box to indicate that sidecar options are now placed in a dedicated tab. Gilles
Note : There is an entry in bugzilla about the all sidecar files support. Look here : https://bugs.kde.org/show_bug.cgi?id=193232 Gilles
Ok, I will do that and follow up in the linked issue as it is exactly about this issue: Closing this issue as duplicate For the bug about separators refer to https://bugs.kde.org/show_bug.cgi?id=379526 (fixed already). *** This bug has been marked as a duplicate of bug 193232 ***
Fixed with #193232