0.82: Categories: Non-selection actions & on-disk metadata
Posted: Wed Feb 01, 2017 8:17 am
In our discussion, in Categories subsystem we distinguish a certain group of actions which are applied to the current selection. These are Add and Remove Category: select some photos, go to Categories Pane and (un)check the desired category - you will see that the said category is correctly (un)assigned both in XnView's DB and on-disk metadata (XMP sidecar and embedded metadata - if the file format supports it).
However there is an important problem with the actions in the Categories subsystem which are not directly tied with a selection: they are actions which usually are management actions directly on the Categories Pane (on tree).
These are (Right-click on the Categories Pane over the tree): Rename, Delete and Merge With... - also Edit.. can trigger a Rename.
Simple steps how to reproduce the problem:
1. In XnView MP assign the category C1 to file F1.jpg
2. Go to Windows Explorer (or any other program with similar capability) to see the file's tags. You will see that C1 is written in F1.jpg as a tag.
3. In XnView MP go to another file (eg. F2.jpg - doesn't matter)
4. Rename C1 to C2 (right-click over the Category - choose Rename...)
Expected: A confirmation message should appear and if we choose {Yes} all the files with C1 should have in the on-disk metadata the new name: C2.
Actual: Nothing happens. The files (including F1.jpg) still have on-disk the old name: C1.
Proposed solution:
An iterator class having as an argument the code to execute which will start with a DSA message saying something like "Do you want to update the on-disk metadata for the changed/deleted category?" {Yes}{No}. - ok, also, the message can be passed as an argument.
If the user will choose {Yes} then the iterator will run the code passed as an argument (RenameCatInFile, DeleteCatFromFile etc.) to each file (if the file is reachable) while a "please wait" gauge will inform us that the program executes a lengthy operation. Of course, if this can be done in a background thread it would be better.
However there is an important problem with the actions in the Categories subsystem which are not directly tied with a selection: they are actions which usually are management actions directly on the Categories Pane (on tree).
These are (Right-click on the Categories Pane over the tree): Rename, Delete and Merge With... - also Edit.. can trigger a Rename.
Simple steps how to reproduce the problem:
1. In XnView MP assign the category C1 to file F1.jpg
2. Go to Windows Explorer (or any other program with similar capability) to see the file's tags. You will see that C1 is written in F1.jpg as a tag.
3. In XnView MP go to another file (eg. F2.jpg - doesn't matter)
4. Rename C1 to C2 (right-click over the Category - choose Rename...)
Expected: A confirmation message should appear and if we choose {Yes} all the files with C1 should have in the on-disk metadata the new name: C2.
Actual: Nothing happens. The files (including F1.jpg) still have on-disk the old name: C1.
Proposed solution:
An iterator class having as an argument the code to execute which will start with a DSA message saying something like "Do you want to update the on-disk metadata for the changed/deleted category?" {Yes}{No}. - ok, also, the message can be passed as an argument.
If the user will choose {Yes} then the iterator will run the code passed as an argument (RenameCatInFile, DeleteCatFromFile etc.) to each file (if the file is reachable) while a "please wait" gauge will inform us that the program executes a lengthy operation. Of course, if this can be done in a background thread it would be better.