“Uh… too bright, but if I set the box color to dark it won’t look good when going back to light theme Oh! It’s smart to use the Alpha channel!”
Redefine Chatting Style to current selection, Set Alpha to 10 for the box color
Apply
See that the text is almost black on dark background, not good!
“Oh? I’ll remove the text color then” and proceed (“no color” make it switch color to keep a contrast with the background)
No change (well it got completely black) Still an issue.
So, in the end I understood that the auto switch of the no-color text based on the background doesn’t take in account the alpha channel of the highlight box color.
Ok, I can just set the box color to a dark one (and no alpha), since I won’t switch often to the light theme.
Yes, the current design was never finished, and it is essentially in a half-broken state as a result. You’re not supposed to have to think about any of this, as all colours used in the editors would adapt the dark or light mode setting (which itself doesn’t even formally exist).
My own person solution is to just pick highlights, text colours and style boxes that look good against a dark background with light text. I never use light mode anyway, but it sounds like that wouldn’t be an option for you.
You mean the dark theme (available by default) wasn’t completely polished?
I had to set the background for notes and comments, and some little UI things are not easy to see (chevrons of the binder, etc), but otherwise I can live with that.
More like any dark mode theme should trigger a number of behaviours that serve to keep colour use in the editor readable, without having to change any of them, so that you can freely switch back and forth without friction. Thus, more of a software handling aspect, than stuff set by the theme settings. But yes, there are a few things about the default “Dark Mode” theme that could use some improvement as well.
Yes, that’s what I thought. Dark vs Light mode should be a matter of quick switch in GUI, and if needed we would have at time two colors to set for one element (one for each mode) when the automatic rule is known to not work well.
Anyway, I tried to fix the comment highlight color. It’s doable but the commented text remains in a strange and ugly color when I set a dark one for the comment. And I couldn’t find how to set it anywhere…
Perhaps this could be useful :
Sometimes when I revise, I like to redact stuff rather than to use strikethrough. (I do not want to see it /read it.)
I designed a character attributes style for that.
When in a style (character attributes style, in this case), the font color reacts to the box’s color.
So black is a no go, as the text I don’t want to see turns white, and is still readable (more than ever).
So my style actually has a light colored box, but also a black highlight.
It works. (And as a bonus, a selection reveals the content.)
Perhaps that could hint at a fix for you. (?) – Use a highlight on top of, or in place of, the box’s background color.
… with character attribute for the style in question.
I see, that’s a good lead to improve the workaround. Thanks for your suggestion!
That said, my understanding is that the character attribute’s highlight ends in the compilation (printable) while the style highlight box doesn’t. Is that correct?
It can be removed at compile in the “Styles” panel.
This said, in my use case I apply this style on very specific bits, and that, furthermore, I plan on deleting anyways.
In your case, you have to think this through first, as it will forfeit your ability to use highlights wherever you applied the said style. (If you remove the highlight at compile, any highlight, even if different, applied after the fact, will inevitably be removed too at compile. You’ll have zero control.) If you want to do this to a whole paragraph, then no. Don’t even consider it. You’ll cause yourself more issues than gain.