GNOME Bugzilla – Bug 733496
Highlight new messages with user-configurable colour
Last modified: 2018-10-25 14:23:47 UTC
At present, new messages in the message list are highlighted by using a bold font. Depending on the scheme used, this can be difficult when trying to identify new messages amongst other mail (ie, when looking through a full list so that context is apparent). I suggest an enhancement to have a user-configurable option to change the font-colour (and possibly other font properties) of unread messages. This would allow users to enhance the contrast to make new messages more apparent in large lists.
should it be that the configuration option references a style, or a specific color/font-pattern [which could then conflict with the system's style potentially making unreadable text?] if it is just a color would the proper place to implement this be in the COL_COLOUR handler used in message-list? Just check for the setting and if set then set the cell to that BG/FG, if not set do what it currently does?
i think an explicitly definable colour/pattern would be the better option - i personally generally prefer darker colour schemes, however often this results in "default" or "based-on-scheme" lists to present almost unreadable text. the ability to say "make new messages bold-red" negates this. and yes, falling back to current behaviour would seem fine, also for backwards compatibility - people updating don't have to worry about digging through preferences to maintain current styling, but those who prefer self-defined colours (and who are more likely to go digging) have the ability to do so.
(In reply to comment #0) > At present, new messages in the message list are highlighted by using a bold > font. Depending on the scheme used, this can be difficult when trying to > identify new messages amongst other mail What is a "scheme" here? It's unclear to me how I can reproduce a situation where bold vs. non-bold is not sufficient for differentiation. Please elaborate. > I suggest an enhancement to have a user-configurable option to change the > font-colour That would collide with the (basically unneeded and useless cruft) option to set colors for messages in the message list via mail filter rules.
(In reply to André Klapper from comment #3) > (In reply to comment #0) > > At present, new messages in the message list are highlighted by using a bold > > font. Depending on the scheme used, this can be difficult when trying to > > identify new messages amongst other mail > > What is a "scheme" here? It's unclear to me how I can reproduce a situation > where bold vs. non-bold is not sufficient for differentiation. No steps provided to reproduce the actual problem, hence closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
I'd like to reopen this bug report, as the issue still persists in version 3.28. To answer the questions from two comments up: > What is a "scheme" here? By "scheme", I believe the original reporter meant the "theme" (e.g. Adwaita vs. Adwaita Dark). > It's unclear to me how I can reproduce a situation where bold vs. > non-bold is not sufficient for differentiation. Please elaborate. I've attached two screen shots of a message list in Evolution, one using the default "Adwaita" theme, one using the "Adwaita Dark" theme. For some reason, bold, dark text on a light background stands out fine; bold, light text on a dark background does not. I'd love to have the possibility to somehow set the font styling on unread messages in my message list.
Created attachment 373281 [details] Message list in Evolution 3.28 using the Adwaita theme Screenshot of message list in Evolution 3.28 using the Adwaita theme.
Created attachment 373282 [details] Message list in Evolution 3.28 using the Adwaita Dark theme Screenshot of message list in Evolution 3.28 using the Adwaita Dark theme.
This had been covered in some for in bug #778180, thus I'm closing this as a duplicate of it. *** This bug has been marked as a duplicate of bug 778180 ***