[GH-ISSUE #190] Text box display colors (custom colors) #111

New issue

Closed

opened 2026-03-03 16:22:28 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 16:22:28 +03:00

Owner

Originally created by @keithknott26 on GitHub (Apr 27, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/190

Hello,

I noticed something when working with the text box when specifying a custom color... the colors that are displayed are different from what you'd expect, you'll need to add one to the color code in order for it to show the color you were after.


	// 11 = yellow
	mqLegendBottom.Write("Result - Dropped ACK\n", text.WriteCellOpts(cell.FgColor(11)))
	//displays as lime green #10

	// 9 = red
	mqLegendBottom.Write("Result - Failed ACK\n", text.WriteCellOpts(cell.FgColor(9)))
	// displays as grey #8

Try this on your side and let me know if you get the same results.

Thanks,
Keith

Originally created by @keithknott26 on GitHub (Apr 27, 2019). Original GitHub issue: https://github.com/mum4k/termdash/issues/190 Hello, I noticed something when working with the text box when specifying a custom color... the colors that are displayed are different from what you'd expect, you'll need to add one to the color code in order for it to show the color you were after. ``` // 11 = yellow mqLegendBottom.Write("Result - Dropped ACK\n", text.WriteCellOpts(cell.FgColor(11))) //displays as lime green #10 // 9 = red mqLegendBottom.Write("Result - Failed ACK\n", text.WriteCellOpts(cell.FgColor(9))) // displays as grey #8 ``` Try this on your side and let me know if you get the same results. Thanks, Keith

kerem

2026-03-03 16:22:28 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-03 16:22:29 +03:00

Author

Owner

@keithknott26 commented on GitHub (Apr 27, 2019):

I should point out that I'm using this chart, which may be different from the one you designed with. Maybe that's the issue? (https://jonasjacek.github.io/colors/) I did notice though that when you specify a line in the linechart and then use that same color code in the text box, they don't often match up.

@keithknott26 commented on GitHub (Apr 27, 2019): I should point out that I'm using this chart, which may be different from the one you designed with. Maybe that's the issue? (https://jonasjacek.github.io/colors/) I did notice though that when you specify a line in the linechart and then use that same color code in the text box, they don't often match up.

kerem commented

2026-03-03 16:22:29 +03:00

Author

Owner

@mum4k commented on GitHub (Apr 27, 2019):

Hey @keithknott26,

thanks for reaching out. This is one of the design decisions that I am not proud of. The color system was implemented very early on and well I didn't know better.

See termbox-go defines value 0 not as the black color but as the default terminal color. It is used when the user didn't provide a color option. This means that black is now color number 1 which makes all the colors off-by-one.

When I implemented our cell API, I have simply copied this without giving it too much thought:
github.com/mum4k/termdash@a9515f2721/cell/color.go (L47-L60)

Later when I realized the off-by-one problem I have added this function:
github.com/mum4k/termdash@a9515f2721/cell/color.go (L62-L74)

So a quick fix for the code you have included is to use this helper:

// 11 = yellow
mqLegendBottom.Write("Result - Dropped ACK\n", text.WriteCellOpts(
    cell.FgColor(cell.ColorNumber(11))),
)

// 9 = red
mqLegendBottom.Write("Result - Failed ACK\n", text.WriteCellOpts(
    cell.FgColor(cell.ColorNumber(9))),
)

Please let me know if this helps as a workaround. Obviously this isn't ideal since it is easy to miss the cell.ColorNumber function. In theory we could still fix this by switching color fields to a pointer and then using nil to represent unset value. Zero could then become black, but at this point this would be a larger change that might break someone. Alternatively we could try to improve the documentation.

Please let me know what you think is best.

@mum4k commented on GitHub (Apr 27, 2019): Hey @keithknott26, thanks for reaching out. This is one of the design decisions that I am *not* proud of. The color system was implemented very early on and well I didn't know better. See [termbox-go](https://github.com/nsf/termbox-go/blob/288510b9734e30e7966ec2f22b87c5f8e67345e3/api_common.go#L135-L145) defines value 0 not as the black color but as the default terminal color. It is used when the user didn't provide a color option. This means that black is now color number 1 which makes all the colors off-by-one. When I implemented our cell API, I have simply copied this without giving it too much thought: https://github.com/mum4k/termdash/blob/a9515f27215c8c7f3c0df731c4e86103cb9cdb9d/cell/color.go#L47-L60 Later when I realized the off-by-one problem I have added this function: https://github.com/mum4k/termdash/blob/a9515f27215c8c7f3c0df731c4e86103cb9cdb9d/cell/color.go#L62-L74 So a quick fix for the code you have included is to use this helper: ```go // 11 = yellow mqLegendBottom.Write("Result - Dropped ACK\n", text.WriteCellOpts( cell.FgColor(cell.ColorNumber(11))), ) // 9 = red mqLegendBottom.Write("Result - Failed ACK\n", text.WriteCellOpts( cell.FgColor(cell.ColorNumber(9))), ) ``` Please let me know if this helps as a workaround. Obviously this isn't ideal since it is easy to miss the **cell.ColorNumber** function. In theory we could still fix this by switching color fields to a pointer and then using **nil** to represent unset value. Zero could then become black, but at this point this would be a larger change that might break someone. Alternatively we could try to improve the documentation. Please let me know what you think is best.

kerem commented

2026-03-03 16:22:29 +03:00

Author

Owner

@keithknott26 commented on GitHub (Apr 27, 2019):

Great! As always I thank you for your detailed response, your workaround works just fine! Really appreciate the help!

@keithknott26 commented on GitHub (Apr 27, 2019): Great! As always I thank you for your detailed response, your workaround works just fine! Really appreciate the help!

kerem referenced this issue

2026-03-03 16:23:18 +03:00

[PR #126] [MERGED] Constructors of all widgets now return an error. #208

kerem referenced this issue

2026-03-03 16:23:18 +03:00

[PR #125] [MERGED] Allow users to provide custom Y axis scale for the LineChart. #209