mirror of
https://github.com/mum4k/termdash.git
synced 2026-04-27 11:25:53 +03:00
[GH-ISSUE #121] Support anchoring or lazy-resize of the Y axis #81
Labels
No labels
bug
cleanup
enhancement
enhancement
enhancement
good first issue
help wanted
help wanted
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/termdash#81
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mum4k on GitHub (Feb 13, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/121
Discussion started in #55.
This is useful for linecharts that continuously pipe data in. By default the scale of the Y axis continuously adjusts according to the currently available min and max value in the presented data set. This can be visually unpleasant and disturbing.
Two options to consider:
Option 1
We could provide an option that let's the caller specify the min and max values of the Y axis, effectively fixing the scale.
Advantages:
Disadvantages:
Option 2
We could implement sort of a "lazy increase" on the Y axis. The scale would still be dynamic, but after the linechart was created it will only increase when it encounters a larger maximum or a smaller minimum. It would never decrease and would be stable for values that fall within the adjusted min-max.
Advantages:
Disadvantages:
Thoughts? Other options?
@keithknott26 commented on GitHub (Feb 14, 2019):
Would it be possible to combine option 1 and option 2? Where the user can set the min/max up front but then if a higher value is encountered the scale would change dynamically, currently (and formerly with termUI based termeter) I was defeating the auto scaling similar to option 1 by simply injecting the max value (of all values) as the first value in the series so that the graph wouldn't encounter a higher value (and continually redraw the scale). In my case, I am recreating the series over and over to move the graph from right to left so it would be ideal if the linechart could accept a specified max value but also "learn" the value for streaming applications.
I can definitely see the value in both methods. As it turned out it was difficult to see overall data trends when the graph was scrolling right to left, when the scale was continually changing. Keeping track of the max or min value would be pretty easy to implement outside of the line chart too, provided the linechart had that option. In most cases, I'll know the maximum value but when streaming data as you point out, the max value wouldn't be known but it could be estimated. If I don't specify the max value, I am facing the problem you mention where the scale adjusts too frequently (since the series changes so often).
Hope this helps!
@mum4k commented on GitHub (Feb 14, 2019):
Thank you for providing the opinion, I think your solution is the best.
This too is fairly simple to implement, so I can target it into the the next release.
@mum4k commented on GitHub (Feb 15, 2019):
This is now available in the devel branch.
@mum4k commented on GitHub (Feb 15, 2019):
To be noted - this came with a breaking change to the LineChart API, the constructor now also returns an error.
Related to #111