mirror of
https://github.com/mum4k/termdash.git
synced 2026-04-27 03:15:55 +03:00
[GH-ISSUE #192] Generilize scrolling and support it in the infrastructure #113
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#113
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 (Apr 28, 2019).
Original GitHub issue: https://github.com/mum4k/termdash/issues/192
Idea proposed by @slok in #164:
Would be nice to mark as scrollable (vertical) any element on the terminal, this is widgets or containers (example a row). I don't know how it would be designed and/or implemented, but I will try to explain:
In the end would be nice to get the same user experience as if you were on a web page, this is, mark a max height on the containers of the grid and if the widgets/containers inside this "scrollable" container are bigger (height) than that, the container would activate the scroll, setting a scroll visualization (could be optional) and giving the user the ability to scroll all the visual stuff inside this container (multiple containers and widgets).
With this, we could gain the ability to create terminal visualizations that aren't limited vertically by the terminal size.
@mum4k commented on GitHub (Apr 28, 2019):
Initial thoughts - this might require updates to the canvas. Widgets could specify (or receive) just the width of the canvas, the height becomes "unlimited". Widgets would draw all the content they want to and the canvas would throw away anything that isn't visible.
The scrolling gets more interesting when enabled on containers that contain other containers. I.e. how will the splitting work, we will probably need to set some "max height" for the container to keep splitting.
Another interesting case is scrollable containers that contain other scrollable containers.
@dyc3 commented on GitHub (Nov 19, 2020):
I don't think it should just be limited to vertical scrolling, because horizontal scrolling would be nice to have for graphs.
@mum4k commented on GitHub (Nov 19, 2020):
That is a good point @dyc3, thank you. If we implement this we should allow scrolling in both planes.
@dyc3 commented on GitHub (Nov 19, 2020):
I think widgets should still receive the width and height of the canvas, except call it a viewport instead, and also provide an x/y offset. This way, widgets would still be in charge of what gets drawn where, and we don't have to worry about really wide or really tall widgets using a lot of memory for their cell buffers.
@mum4k commented on GitHub (Nov 19, 2020):
Very good points, this would give the control completely to widgets. They would be able to choose if they want to potentially utilise more space than is allocated to them in the container. I also like the obvious memory usage optimisation as you have suggested.
The above approach is applicable when we enable scrolling on a single container that directly contains a widget. What might be worth discussing is how to approach a case where scrolling is enabled on a container that contains further containers. Say an entire half of a screen. But we might as well decide that these are two different features and only one of them is worth addressing.