"Smart" colors

[aleho]

Some color setups (I prefer dark backgrounds e.g.) might lead to text not being readable - especially if an application sets text color without a "matching" background.

I propose "intelligent" colors that are changed depending on contrast between background and foreground.

Is this something that could be done in Tilix or are there changes to libvte necessary?

[egmontkob]

On Mac, the default Terminal.app as well as the popular iTerm2 alternative have such a "minimum contrast" feature.

For Tilix, a new feature (and API) in VTE would be required for this.

[aleho]

So Tilix has no way of knowing which color is being displayed? 😢

The actual minimal contrast check is pretty easy to implement (and cheap regarding resources), so this could be done "on the fly" as well.

[egmontkob]

So Tilix has no way of knowing which color is being displayed?

Not really, nor has it any way of influencing it.

pretty easy to implement

What's the required formula?

Is it always the foreground color that's modified?

In which direction to start looking for the new color? Is it as simple as continuing along the (background -> foreground) three-dimensional vector (with R, G, B components) further in the same direction? What if a "wall" is hit, i.e. one of the numbers would leave the (0, 255) interval?

How to compute the contrast? Is it abs(r1-r2) + abs(g1-g2) + abs(b1-b2) as suggested at https://www.w3.org/TR/AERT#color-contrast (stating "This is a suggested algorithm that is still open to change") [does the standard really misspell "range" as "rage"???], or the Pythagorean formula sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2), or maybe something even more complex, and why? I've seen several folks complaining that xterm's approximation of true colors to the 256-color palette is pretty bad as it doesn't take human perception of colors into account. See e.g. the comments of https://gist.github.com/XVilka/8346728 dating May 14 & 21, 2016; perhaps there are other relevant comments too.

Should such modification be done even if RGB escape sequences are used, or only for the 256 palette colors, or only for the 16 legacy ones?

What to do if the foreground color is exactly same as the background?

What to do if the "invisible" ANSI attribute is set?

What to do if the background is translucent or entirely transparent?

Anyway, this should be discussed in the VTE bug tracker :)

[egmontkob]

See however the discussion at https://bugzilla.gnome.org/show_bug.cgi?id=758368, especially the callback API in comment 2. Maybe that thread should be revived, with a slight modification: It shouldn't be individual colors, rather (fg, bg) color pairs passed to the callback to mangle.

Then all the concerns I've outlined here in my previous comment would be Tilix's (or whichever VTE-based emulator's) problem and not VTE's :-)

[gnunn1]

As @egmontkob noted Tilix only knows what the current palette is, it has no way of knowing what colors the terminal application is actually using. As noted I think this is best handled in VTE, hence I'm closing this has an upstream issue.

[egmontkob]

@gnunn1 Would you implement this feature (and would you perhaps simplify the dimming code by using VTE's color mangling API) if such an API was available?

I'm tempted to implement it, but I definitely won't if nobody's interested :)

[gnunn1]

You mean an API to determine what colors each cell being displayed is using and then from there I'd need to implement the color changing algorithm? The problem for me is I'm not sure what's involved on the algorithm side, I'd certainly look at but I'll be honest and say color processing is not my forte.

If you are looking for something to implement, mainlining the patch needed for badges would be something I would use. It's been on my todo list forever but I'm swamped at work to the point where I can't spend the time getting my C-foo up too snuff to do it.

[egmontkob]

Color changing: Exactly. I'm not good in color processing either, that's why I'd delegate it to the container app :) Okay, seriously, I'd delegate it for more flexibility.

Badges is another story. I made my comments there but I'm not aware of the technical details (it was somehow hijacking the draw signal??) and I'm afraid I don't share the same vision here with the main developer.