Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generilize scrolling and support it in the infrastructure #192

Open
mum4k opened this issue Apr 28, 2019 · 5 comments
Open

Generilize scrolling and support it in the infrastructure #192

mum4k opened this issue Apr 28, 2019 · 5 comments
Labels
enhancement New feature or request

Comments

@mum4k
Copy link
Owner

mum4k commented Apr 28, 2019

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
Copy link
Owner Author

mum4k commented 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.

@mum4k mum4k added the enhancement New feature or request label Apr 28, 2019
@dyc3
Copy link
Contributor

dyc3 commented 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
Copy link
Owner Author

mum4k commented Nov 19, 2020

That is a good point @dyc3, thank you. If we implement this we should allow scrolling in both planes.

@dyc3
Copy link
Contributor

dyc3 commented 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
Copy link
Owner Author

mum4k commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants