[digikam] [Bug 379511] New: Introduce additional sidecar types and fix bug in mime setup [patch]

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

            Bug ID: 379511
           Summary: Introduce additional sidecar types and fix bug in mime
                    setup [patch]
           Product: digikam
           Version: 5.6.0
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: setup
          Assignee: [hidden email]
          Reporter: [hidden email]
  Target Milestone: ---

Created attachment 105344
  --> https://bugs.kde.org/attachment.cgi?id=105344&action=edit
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.

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

Simon <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #105344|0                           |1
        is obsolete|                            |

--- Comment #1 from Simon <[hidden email]> ---
Created attachment 105345
  --> https://bugs.kde.org/attachment.cgi?id=105345&action=edit
Introduce additional sidecar types and fix bug in mime setup - 2

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #2 from [hidden email] ---
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

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

--- Comment #3 from Simon <[hidden email]> ---
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?

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

--- Comment #4 from [hidden email] ---
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

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

--- Comment #5 from [hidden email] ---
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

--
You are receiving this mail because:
You are the assignee for the bug.

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=379511

Simon <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #6 from Simon <[hidden email]> ---
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 ***

--
You are receiving this mail because:
You are the assignee for the bug.