[GH-ISSUE #183] Support "dot" character in SegmentDisplay

kerem commented

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

Owner

Originally created by @slok on GitHub (Apr 8, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/183

Originally assigned to: @mum4k on GitHub.

Hi again @mum4k!

Displaying floats on the segment display in metrics is a common use case, the problem is that the segment display doesn't have support for point (.) character, would be nice to have support for this character.

Example of how it renders the floats at this moment (0.267 without dot):

Thank you!

Originally created by @slok on GitHub (Apr 8, 2019). Original GitHub issue: https://github.com/mum4k/termdash/issues/183 Originally assigned to: @mum4k on GitHub. Hi again @mum4k! Displaying floats on the segment display in metrics is a common use case, the problem is that the segment display doesn't have support for point (`.`) character, would be nice to have support for this character. Example of how it renders the floats at this moment (`0.267` without dot): ![](https://i.imgur.com/f8wsvkQ.png) Thank you!

kerem

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

closed this issue
added the
enhancement
label

kerem commented

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

Author

Owner

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

Thanks again @slok, indeed the dot character isn't supported which bothered me while I worked on the segment display.

I can't pick this up right away as I would like to land few infrastructure improvements first, but I think it is a good idea to document my original plan here. In case someone else gets to this before me.

The SegmentDisplay widget translates characters into segments. There could be multiple implementations of a segment, but currently only one exists, the 16-segment display:

github.com/mum4k/termdash@a9515f2721/internal/segdisp/sixteen/sixteen.go (L24-L38)

My original plan was to implement another segment type which would only contain dots. It could look like this:

     -------
    |       |
    |       |
    |   O D1|
    |       |
    |       |
    |       |
    |       |
    |       |
    |   O D2|
    |       |
    |       |
     ---O-D3

The scale should probably be adjusted, the idea is that it will be roughly half the width of a typical 16-segment and contain three dots. The lines aren't part of the segment, they just illustrate its boundaries. It will be capable of displaying the dot (.) and the colon (:) characters.

The SegmentDisplay widget can then be adjusted so that when it encounters dots or colons it would use this new DotSegment(?) instead of the 16-Segment.

Feel free to let me know if I missed anything or if you have suggestions.

@mum4k commented on GitHub (Apr 9, 2019): Thanks again @slok, indeed the dot character isn't supported which bothered me while I worked on the segment display. I can't pick this up right away as I would like to land few infrastructure improvements first, but I think it is a good idea to document my original plan here. In case someone else gets to this before me. The [SegmentDisplay](https://github.com/mum4k/termdash/blob/master/widgets/segmentdisplay/segmentdisplay.go) widget translates characters into segments. There could be multiple implementations of a segment, but currently only one exists, the 16-segment display: https://github.com/mum4k/termdash/blob/a9515f27215c8c7f3c0df731c4e86103cb9cdb9d/internal/segdisp/sixteen/sixteen.go#L24-L38 My original plan was to implement another segment type which would only contain dots. It could look like this: ``` ------- | | | | | O D1| | | | | | | | | | | | O D2| | | | | ---O-D3 ``` The scale should probably be adjusted, the idea is that it will be roughly half the width of a typical 16-segment and contain three dots. The lines aren't part of the segment, they just illustrate its boundaries. It will be capable of displaying the **dot** (.) and the **colon** (:) characters. The SegmentDisplay widget can then be adjusted so that when it encounters dots or colons it would use this new DotSegment(?) instead of the 16-Segment. Feel free to let me know if I missed anything or if you have suggestions.

kerem commented

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

Author

Owner

@slok commented on GitHub (Apr 9, 2019):

Understood! makes a lot of sense what you say

Thanks for taking the time to explain.

@slok commented on GitHub (Apr 9, 2019): Understood! makes a lot of sense what you say Thanks for taking the time to explain.

kerem commented

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

Author

Owner

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

Hey @slok,

with the text input field done recently I have some spare cycles and can look at this or something else.

Would you say that this is the most important missing feature for you or would you like to see something else done first?

@mum4k commented on GitHub (Apr 27, 2019): Hey @slok, with the text input field done recently I have some spare cycles and can look at this or something else. Would you say that this is the most important missing feature for you or would you like to see something else done first?

kerem commented

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

Author

Owner

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

Hey @mum4k, first of all, thanks for asking my opinion, that means a lot :)

Regarding the issue I think is important, almost at the same level as these:

#85
#105 (this way the linechart can filter the series show with the selectors or change the metrics query used to retrieve the series from the metrics datasources).
#164 (but supporting containers or elements, this way we can scroll a full terminal dashboard, I don't know if this is possible).

But if I have to choose one to prioritize, I would select this issue (#183). With this issue and #188 closed, I could release the 0.1.0 version of grafterm(and publish the source 🎉 ).

@slok commented on GitHub (Apr 27, 2019): Hey @mum4k, first of all, thanks for asking my opinion, that means a lot :) Regarding the issue I think is important, almost at the same level as these: - #85 - #105 (this way the linechart can filter the series show with the selectors or change the metrics query used to retrieve the series from the metrics datasources). - #164 (but supporting containers or elements, this way we can scroll a full terminal dashboard, I don't know if this is possible). But if I have to choose one to prioritize, I would select this issue (#183). With this issue and #188 closed, I could release the `0.1.0` version of `grafterm`(and publish the source :tada: ).

kerem commented

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

Author

Owner

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

Thank you @slok, this list is very helpful. The choice of what to work on is best made in the context of what users need.

I think we can close this issue and #85 fairly quickly so I will work on these two next.

We could target #105 for the next release, I would love to hear your and Keith's thoughts on how important it is compared to #104 and #5. I will open an issue for us to discuss features for the next release soon.

#164 was more about scrolling within widgets. I would be interested to hear more about your idea of scrolling the full dashboard, can you share some thoughts in #164 when you get some time?

@mum4k commented on GitHub (Apr 27, 2019): Thank you @slok, this list is very helpful. The choice of what to work on is best made in the context of what users need. I think we can close this issue and #85 fairly quickly so I will work on these two next. We could target #105 for the next release, I would love to hear your and Keith's thoughts on how important it is compared to #104 and #5. I will open an issue for us to discuss features for the next release soon. #164 was more about scrolling within widgets. I would be interested to hear more about your idea of scrolling the full dashboard, can you share some thoughts in #164 when you get some time?

kerem commented

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

Author

Owner

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

@mum4k ,

It's hard to say, I know you've put significant work into #5 already, I can comment that #105 would be a very nice feature to have as I have a couple projects going on right now that could use the dropdown/select menu. I've worked around this by having the user specify arguments at startup - certainly a great addition for the user to be able to select things during runtime though. I suppose I could just use the button in the meantime so in my mind that lowers the priority slightly.

Nice work on the text input box by the way!! That went together much faster than I thought, great job!

@keithknott26 commented on GitHub (Apr 27, 2019): @mum4k , It's hard to say, I know you've put significant work into #5 already, I can comment that #105 would be a very nice feature to have as I have a couple projects going on right now that could use the dropdown/select menu. I've worked around this by having the user specify arguments at startup - certainly a great addition for the user to be able to select things during runtime though. I suppose I could just use the button in the meantime so in my mind that lowers the priority slightly. Nice work on the text input box by the way!! That went together much faster than I thought, great job!

kerem commented

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

Author

Owner

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

Thank you @keithknott26 for chiming in and helping us decide. It is true that we have made some investment into #5 already, but we can finish that at any time. To be fair it will most likely take another month to finish it so it probably is the right choice to keep it shelved until we need it.

Looks like #105 would be useful for both your projects so let's target it for 0.10.0. I also believe that we could benefit from adding more interactive widgets.

Thanks for the feedback on the text input, as always your help in testing it and finding issues I missed is much appreciated.

@mum4k commented on GitHub (Apr 28, 2019): Thank you @keithknott26 for chiming in and helping us decide. It is true that we have made some investment into #5 already, but we can finish that at any time. To be fair it will most likely take another month to finish it so it probably is the right choice to keep it shelved until we need it. Looks like #105 would be useful for both your projects so let's target it for 0.10.0. I also believe that we could benefit from adding more interactive widgets. Thanks for the feedback on the text input, as always your help in testing it and finding issues I missed is much appreciated.

kerem commented

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

Author

Owner

@mum4k commented on GitHub (May 1, 2019):

Pushed to the devel branch.

Please let me know in case of any issues with the new code.

@mum4k commented on GitHub (May 1, 2019): Pushed to the devel branch. Please let me know in case of any issues with the new code.

Rows
Columns

[GH-ISSUE #183] Support "dot" character in SegmentDisplay #106