Bug 430311

Summary:	Intensive color selection broken as of 270d6ea3
Product:	[Applications] konsole	Reporter:	Antonio Russo <aerusso>
Component:	font	Assignee:	Konsole Developer <konsole-devel>
Status:	REPORTED ---
Severity:	normal	CC:	andre.vmatos, anthony.vital, dos, javi, jkhsjdhjs, keikoz, luke-jr+kdebugs, nl6720, quantumphazor, rherbert, ricardo, sombragris
Priority:	NOR
Version:	20.12.0
Target Milestone:	---
Platform:	unspecified
OS:	All
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Antonio Russo 2020-12-12 17:43:23 UTC

SUMMARY

Commit 270d6ea3247bb41a51535129e4b1c8eef51cf316 breaks the ability to use intensive colors. This commit claims to fix the readability issue 405345, but the bug reporter indicated in

https://www.mail-archive.com/kde-bugs-dist@kde.org/msg343586.html

that the bug was fixed by an unrelated commit a year prior.

The motivation for removing the intensive color, as far as I can tell, is laid out in

https://www.mail-archive.com/kde-bugs-dist@kde.org/msg341954.html

However, this email by a non-KDE developer misses that, if you want to not have an intense color, you can simply choose a color scheme that has the same normal and intense color settings. That comment raises as an issue, black-on-white color schemes readability.

STEPS TO REPRODUCE
1. Request an intensive font color in the color selection dialog, or use a standard font color scheme with intense colors.
2. Print an intensive font color, i.e., echo -e '\e[1mfoobar

OBSERVED RESULT

The color of the font is not as requested, it is simply the normal color.

EXPECTED RESULT

The color of the font should be as specified in the intense color column.

SOFTWARE/OS VERSIONS
This is present as of 270d6ea3247bb41a51535129e4b1c8eef51cf316 in master, or 82806a2c129f8fa4b21be25b4108eecd8d460625 in 20.12.0, which cherry picks that commit.

ADDITIONAL INFORMATION

A better solution to the readability issues raised in

https://www.mail-archive.com/kde-bugs-dist@kde.org/msg341954.html

is to use the existing robust configuration options available to adjust the dark-on-light color schemes to have richer, rather than fainter, intense colors. There is no reason to remove simultaneously remove a configuration option, and change the default behavior that users have expected for over a decade.

I propose to revert the commit in question, and adjust the defaults in the dark-on-light color schemes.

P.S. The default colors in the faint categories are probably my fault (sorry)---I chose them somewhat randomly back when I implemented faint color support.

Comment 1 kero 2020-12-13 17:21:36 UTC

I'm not sure if this is completely related, but since the last update the intense colors are no more applied in Konsole though the option "Draw intense colors in bold font" is selected.

Comment 2 sombragris 2020-12-13 19:38:36 UTC

Confirmed after upgrading to release service (applications) 20.12.
I think it should be applied to konsolepart since other apps such as yakuake suffer from this bug.

Please fix ASAP. Thanks!!

Comment 3 Antonio Russo 2020-12-14 06:20:30 UTC

My initial description of the bug is not quite correct, so please see

https://invent.kde.org/utilities/konsole/-/merge_requests/299

where I've implemented an option to allow for both the old and new behavior.  The patch applies on top of 20.12.0---and in fact is what I'm testing with.

I'd appreciate anyone willing to test this out and give feedback---please notice that the tests I have run right now are VERY MINIMAL.

That said, I am planning on using it on my personal machine.

Comment 4 Sebastian Krzyszkowiak 2020-12-17 01:59:18 UTC

(In reply to Antonio Russo from comment #3)
> I'd appreciate anyone willing to test this out and give feedback---please
> notice that the tests I have run right now are VERY MINIMAL.

Thanks a lot! My terminal is readable again on "Linux Colors" scheme with your patchset :)

Comment 5 Andrew M 2020-12-17 05:50:31 UTC

Thanks. Reverting commit 270d6ea3 restores the previous colours for me.

Comment 6 Antonio Russo 2020-12-19 19:59:12 UTC

This is fixed as of 2d58ed02.  I'm leaving this open, since it's still broken in 20.12.0.

Comment 7 Luke-Jr 2020-12-24 19:47:48 UTC

My preferred console font doesn't even support literal bold. I wasn't aware there were people who actually want such a thing.

As for the rationale that there is no other "bold alone" code... Shouldn't it work to specify (eg) \e[1m\e[38;2;50;50;50m ?

I also notice the intensive behaviour already (before this bug was introduced) ignored RBG colours... So you don't even need to put the colour after the bold code.

Comment 8 Antonio Russo 2020-12-24 20:30:51 UTC

FYI: This has been merged into the 20.12 release branch, so it should be fixed in 20.12.1 .

There's also a patch (I wrote) that adds a configuration option for the alternative behavior, so it's unlikely we'll see another regression.