Add a discriminating font color for tags that are left untouched because MB has no content to offer

Picard has very useful font color indications that shows what it will do with tags before you press ‘save’.

Tags that will be deleted are red, retrieved tags that differ from already present tags are brown, tags that were not present in the file before are green.

But there are two possibilities that don’t have discriminating colors.

  1. The content was already present in the file and identical with what was retrieved from MB
  2. The content was already present in the file and MB had no data to offer for it.

Both will be formatted in a black font.
So you won’t know if the tag was matching with what MB had to offer, or if MB had nothing to offer and leaves the tag untouched.

My suggestion/request: change the coloring to some lighter gray for tags that are present in the file but MB has nothing to offer for and will be untouched.

Picture, 1000 words, etc:

(in this example ‘Mood’ is the tag that MB offers no content for and will remain untouched)

4 Likes

I suggested this on the old forums and a ticket was created for it: https://tickets.metabrainz.org/browse/PICARD-250.

4 Likes

Ah, funny, that looks like a seven year time-machine inverted copy/paste of my post.
I went back in time and voted on it. :wink:

1 Like

It is the Ticket System… time follows different rules inside a black hole… :wink:

With your example above and the colours. What is “Clear existing tags” set to? I assume that is unticked. So how would some items (Barcode) get removed and others (mood) kept? Wouldn’t mood just stay black as “something to be kept\not changed”?

Isn’t your request more along the lines of - highlight the stuff in my “Preserve these Tags” list?

Nope, I have it ticked here.
Mood is probably left alone because Picard usually has no purpose for that one since (I think) it is not a tag that will be retrieved from MB.

But in that scenario, with “clear existing tags” set, then it should be clearing “mood” as well. So mood would not have any value to put back.

Mood was listed under ‘preserve tags…’

In that case I’d tweak the request to - “a different colour for preserve tags matches”.

That way it simplifies the question.

That way you have brown for changes, red for delete, black for no change but added highlight for “preserve tags”

No, that’s not accurate. If you don’t have ‘clear all tags’ ticked, and you have nothing under ‘preserve tags…’, the same issue is at play.

I believe my original request, combined with culinco’s ticket is clear enough to the guys that may possibly be able to add this.

1 Like

There’s also my ticket for changing the behavior of preserved tags, so you don’t need to guess which tags are preserved anymore: https://tickets.metabrainz.org/browse/PICARD-1103 (it could just be made into a plugin). I’d really like if we could have some indicators in the tag rows in addition to the current colors, so the user won’t need to do all the guesswork to know which colors do what.

That’s something I know I have brought up in the past too.
(just can’t find it right now)

My suggestion was to have the tag name greyed out.
That might look a little bit cleaner and be more straightforward than the proposal you had for it?

But then we would have grey contents for tags that don’t match mb data and grey tag names + contents for preserved tags, which would make it even more confusing imo. On top of that I’d like to see the differences between the file tags and mb data even for preserved tags, which is why I created that ticket in the first place.

I don’t see what would be confusing.

When the Tag Name is greyed out, that strictly indicates that the tag is present in your ‘preserve tags’ list.

When data in the right panel is greyed out, you can still compare it with the value that is currently present in the file.

Greyed out values in the right panel simply indicate that those values will not be written, and:

  • when the Tag Name in front of it is greyed out, you’ll know that that is because the tag is in your ‘preserve tags’ list.
  • when the Tag Name is not greyed out you’ll know that it is not written because MB offers no content to replace the original value with.

I believe greying-out text is a very universal concept, and most users will immediately understand what it means without doing much research.
To me this seem like a very natural and intuitive improvement to the current situation.

My point is that if the values for preserved tags would be grey, you can’t tell whether they match the mb data or not. See my second screenshot on the ticket I linked above, the title and album tags are different, but the artist matches mb data. If all of them would be grey, you wouldn’t be able to tell whether they match mb data or not (which is the current behavior).

How about this:

The grey tag name indicates it is in your ‘preserved’ list, the blue font is an extra visual indication that those tags will be preserved unchanged because of that.

1 Like

“New value” column should have the value the tag will contain after the file is saved. If the tag is in the preserved list, “new value” and “original value” should display the same thing. (Does “preserve tags” list also prevent manual modification?)

1 Like

I can agree with that point.
I added the blue font thing to see if I could find a creative way to additionally accomodate for culinco’s wish.
But that’s going to be hard with only doing font colouring.

So for now I’ll stick to my original idea/suggestion for greying out tags that MetaBrainz offers no content for, and greying out ‘preserved tags’:

The only complete solution might be involving adding a new column in Picard called something like ‘MusicBrainz’.

Then you would have:

  • The tags present in your files in the first column.
  • Tags retrieved ‘as is’ from MusicBrainz in the second column.
  • The resulting tag to be written using your current settings/scripts in the third column.

Actually, coming to think of it, if Picard would have had that from day 1 when I started to try it out, it would have taken me a lot less time and frustration before understanding Picard better.

Anyway, that’s drifting away from the original subject here about font colouring, so I created a new thread about this ‘third column’ idea in case anybody else has some ideas about that:

1 Like

My point is, if there are only minor differences between “Actual data” and “Updated data available” (e.g. unicode punctuation), you can’t tell if the two values are identical or different if they share the same grey color. That’s why I like the “orange” color indicating that the two values are different.

Well, this is the current behavior and my ticket talks about having a setting (or a plugin) to change this behavior to show mb data in the “new value” column for preserved tags even if they won’t be overwritten. So the logic for “new data” column wouldn’t be what is being written into tags but “data from mb” (after being processed by plugins and scripting). I guess my ticket is not relevant to this discussion and is a different setting/feature.

Some nice suggestions in this thread, here are few comments.

Using fixed colors to differentiate things isn’t great from accessibility POV, and compatibility with themes, so discussing colors don’t make much sense. Picard is already using too much of this IMHO, and should be fully configurable color-wise.

Adding a column would not be convenient for all, so it would have to be configurable. User should be able to actually choose what he wants to display (original tags, MB tags, script-modified tags, final tags, etc…). If we keep columns, position and display of each should be configurable (context menu?).

Also, currently, even if there are differences between tags, it’s not always easy to know what changed (especially with visually similar Unicode characters), I’d like to move to diff-like display (highlighting changes in each string).

Patches are welcome.

3 Likes

Thanks for the feedback @Zas.

Input from a coder with more insight and knowledge is very useful to prevent us mortals from spending too much time on ideas that are not realistic or easily achievable.

Hopefully some of your suggestions for improvements will bear fruit and become reality some day.

For the meantime, I personally don’t agree with your dislike for colouring.
Certainly in the way that it is currently done in Picard I find it extremely useful.

Red for deletion, green for new, brown for differences, I like it a lot.

And as I said earlier, greyed out text I think is a widely understood concept and wouldn’t make the interface more confusing in my opinion.
And the benefit that you can then immediately see that a tag is present in your ‘preserve tags’ list is worth it in my opnion.

(and, is grey a color anyway? :wink: )

Well, I think the thread has been interesting and colourful.
I think I presented my thoughts and opinions more than enough by now and will probably leave it at this.