Support "dot" character in SegmentDisplay

[slok]

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!

[mum4k]

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:

termdash/internal/segdisp/sixteen/sixteen.go

Lines 24 to 38 in a9515f2

	A1 A2
	------- -------
	| \ | / |
	| \ | / |
	F | H J K | B
	| \ | / |
	| \ | / |
	-G1---- ----G2-
	| / | \ |
	| / | \ |
	E | N M L | C
	| / | \ |
	| / | \ |
	------- -------
	D1 D2

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.

[slok]

Understood! makes a lot of sense what you say

Thanks for taking the time to explain.

[mum4k]

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?

[slok]

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:

• Support displaying a text label under the Donut widget #85
• Widget: Select / datalist #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).
• Implement a scrollbar for widgets that support scrolling #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 🎉 ).

[mum4k]

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?

[keithknott26]

@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!

[mum4k]

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]

Pushed to the devel branch.

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