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? 
)
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.
When @zas mentioned “accessibility” he is referring to people who are colour blind. Not everyone can see colour so you need to make sure there are options for those with differing abilities.
1 Like
I understand that, but there are many kinds and degrees of colour blindness.
You can’t create one colouring scheme that is great for all sufferers from a variation of colour blindness.
Surely it is laudable to try and limit the chances of issues here, but reducing the use of sensible colours that are not a problem at all for the vast majority of users, and so decreasing the user experience for the vast majority is not the best way to go.
The best and probably only way that would really benefit such users is to make the colours fully adjustable.
The option to be able to change colours will probably be a blessing for them.
But reducing Picard’s colour variations will probably benefit almost nobody.
(but of course the use of too many of them can also become a problem at a certain point)
b.t.w.
I noticed Zas mentioning themes.
I have no idea if they exist, but if they are available, e.g. high-contrast, different colouring, larger fonts, etc, that is a great for people with visual handicaps.
Are there indeed themes available somewhere?
You misunderstood. I’m not against using colours, but i’m against hardcoding them. That’s something that needs to be fixed in Picard, so instead of discussing which colour we should use for what at this point, I’d rather define roles and allow user to associate whichever colour he wants for each. We can define default colours though, of course.
According to http://www.colourblindawareness.org/colour-blindness/: “Worldwide, there are approximately 300 million people with colour blindness”.
2 Likes
Ah, yes, I read that you thought there were too many colours in Picard already, but you meant too many hard-coded colours.
coder vs. human
Not yet, mostly because of Picard messy code.
Qt has now full support for color themes, for widgets and text, through stylesheets and rich text (html-like), so it’s all about changing existing code to actually support those.
1 Like
Let’s hope one of the 300 million has some time and talent to help with that
This. Cool.
No need for me to reply line by line as I like the idea here and agree with your general scheme hiccup… just gotta make sure everyone can use it. 
#Coders are Human Too!
(Well… some of them are…)
Forgive me if I misunderstand again.
Wouldn’t that mean that my initial suggestion about having differentiating colours for ‘preserved tags’ and for ‘tags that are offered by MB but not actually (re)written’ is exactly that?
It is. I just wanted to be sure everyone discussing about colours is aware about color-blindness and implications it has when it comes to UI design.
5 Likes
Ok. But it looks like we are now back at square 1 in this thread.
What would be the next step, if there is any?