Issue Details (XML | Word | Printable)

Key: PICARD-193
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: Michael Wiencek
Reporter: voiceinsideyou
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Picard

Make remove tags logic in MetaDataBox more intuitive/flexible

Created: 26/May/12 05:37 AM   Updated: 27/May/12 08:20 PM   Resolved: 27/May/12 08:20 PM
Component/s: Tags & Metadata
Affects Version/s: 1.0
Fix Version/s: 1.0

Issue Links:
Relates
 


 Description  « Hide

Loving the new metadatabox, but think the logic here could be a little bit smarter and more flexible. I understand that with current Picard implementation that if you don't have clear_existing_tags selected then this means it can't remove an existing tag from one of your files. This makes sense.

However this logic makes the behaviour a bit inconsistent between situations when you do and do not have files matched/linked to MB metadata. Currently if you don't have any files linked, since everything is considered "Added" you can click "Remove tag" which appears to cause it to be removed from the MB/"new" metadata. When you later link a file, the "new" tag is gone, which is exactly what one would expect.

However once you've already matched/linked 1+ files, there's no easy way to achieve this that I can see. It'd be nice if there was an easy way to essentially say "Reset to original value" even once it's linked that behaves essentially the same as when you click "Remove tag" without linking anything.

I'd actually quite like to make it consistent in naming between the two approaches but can't quite think of a good description that makes sense in both cases, and also makes sense when removing "newly added" tags. Would it make sense for "Reset to original value" to cause complete removal of a tag if you didn't already have it in your file; or if the file is not already linked? Maybe?

Assigning you for comment Michael, not to require you to do anything nor agree



Sort Order: Ascending order - Click to sort in descending order
Michael Wiencek added a comment - 26/May/12 06:20 AM

Ideally I'd prefer letting users manually remove existing tags regardless of clear_existing_tags, but it's hard to implement.

I see what you mean about the "reset to original value" idea. There's actually a new setting that prevents Picard from modifying certain tags now, but there should be a manual override in the metadatabox too. I'm in favor of adding "reset to original value" to the context menu there.

How about this option is separate from "remove," and is only available when you right click an existing tag that's being changed (yellow)? It could possibly be named "ignore this change," but your suggestion is fine too.


Michael Wiencek added a comment - 26/May/12 06:22 AM

Now that I think about it, wouldn't that do the same thing as "copy to new value"? I might be confused.


voiceinsideyou added a comment - 26/May/12 08:08 AM

Oh my gosh, I feel stupid now. I didn't even see the "copy to new value" setting.

But I guess this highlights a bit of the confusion over what you can do driven from column 1 vs column 2. Why don't we try and make this context menu the same for the whole row (not column dependent); and make it obvious what it's effecting?

If it were named "Reset new value to original value" you could call it the same thing across all columns and then unify the context menu, right?


Michael Wiencek added a comment - 26/May/12 08:27 AM

Well you bring up a good point, that it's confusing to have these column-dependent menus. It should be accessible from both. "Reset new value to original value" is a good way to unify it, though I'd prefer something a bit shorter like "{use,keep} original value," unless you feel that sacrifices clarity too much.


voiceinsideyou added a comment - 26/May/12 08:44 AM

Yeah, was trying to think of something shorter. "Use original value" is probably sufficient, yeah.