You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.
Hi there, I've been using tui-rs for a bit on personal projects, and I think it's great!
In the app I'm working on at the moment, I've implemented a view into a large logical coordinate space for displaying nested data (think nested arrays, maps, strings, etc rendered as text like you'd see in program source code or JSON). Because the rendered data in general will be larger than the screen, there has to be a notion of a visible "screen rect" which scrolls around the "canvas rect" (just like how a web browser presents a visible portion of any given webpage which might be larger than the view).
The problem is that Widget and StatefulWidget are rendered using screen coordinates which are necessarily u16-valued. This means that you can't "just render" a partially occluded widget that sticks off the edge of the screen, as it must when the view can scroll around the canvas. With the Paragraph widget, there is a scroll function which has allowed me to emulate this behavior, but I've had to implement my own "canvas coordinate system" in order to handle positioning, visibility culling, and Paragraph-scrolling of the elements on the canvas. Now I'm looking to add Blocks to my rendering, but they don't have a scroll function, so I can't do this emulation, and I'm stuck. The only thing I can think of is a hack in which I disable the various borders and title of the Block if those borders would be outside the visible rect, but this seems very messy and fragile.
So my question at the moment is - is there any immediate way to handle this without being too ugly?
I think in the long term, the robust solution would be to:
Use signed ints for screen coordinates and rendering commands (probably i32, but maybe leave as a generic in case you wanted smaller or larger ranges).
Have the rendering code handle rendering of elements that are partially occluded, and not render elements that are totally out-of-view.
Have a "canvas" mechanism (maybe a StatefulWidget?) which handles this logic and establishes an "interior" coordinate system, so that you can have a widget which represents a scrollable view into a larger canvas (many existing precedents in common GUI).
In particular, it should be possible to implement a multi-pane view program, in which each pane is a view into a large document and can scroll independently.
It's already almost possible to implement this "canvas" concept as a StatefulWidget using tui-rs as is, except for rendering partially-occluded widgets (e.g. Block), so really the lift would be in allowing widgets to be rendered with partial occlusion.
Has there been any planning or thinking on this front? I'd be interested in contributing to a solution here.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi there, I've been using tui-rs for a bit on personal projects, and I think it's great!
In the app I'm working on at the moment, I've implemented a view into a large logical coordinate space for displaying nested data (think nested arrays, maps, strings, etc rendered as text like you'd see in program source code or JSON). Because the rendered data in general will be larger than the screen, there has to be a notion of a visible "screen rect" which scrolls around the "canvas rect" (just like how a web browser presents a visible portion of any given webpage which might be larger than the view).
The problem is that Widget and StatefulWidget are rendered using screen coordinates which are necessarily u16-valued. This means that you can't "just render" a partially occluded widget that sticks off the edge of the screen, as it must when the view can scroll around the canvas. With the
Paragraph
widget, there is ascroll
function which has allowed me to emulate this behavior, but I've had to implement my own "canvas coordinate system" in order to handle positioning, visibility culling, and Paragraph-scrolling of the elements on the canvas. Now I'm looking to addBlock
s to my rendering, but they don't have ascroll
function, so I can't do this emulation, and I'm stuck. The only thing I can think of is a hack in which I disable the various borders and title of the Block if those borders would be outside the visible rect, but this seems very messy and fragile.So my question at the moment is - is there any immediate way to handle this without being too ugly?
I think in the long term, the robust solution would be to:
i32
, but maybe leave as a generic in case you wanted smaller or larger ranges).In particular, it should be possible to implement a multi-pane view program, in which each pane is a view into a large document and can scroll independently.
It's already almost possible to implement this "canvas" concept as a StatefulWidget using
tui-rs
as is, except for rendering partially-occluded widgets (e.g. Block), so really the lift would be in allowing widgets to be rendered with partial occlusion.Has there been any planning or thinking on this front? I'd be interested in contributing to a solution here.
Beta Was this translation helpful? Give feedback.
All reactions