A few ideas from developing a non-trivial application with cursive
- Dominant language
- Rust
- Stars
- 4.8k
- Forks
- 270
- Avg merge
- 5d 19h
- Merged PRs (30d)
- 2
Description
I developed [resctl-demo](https://github.com/facebookexperimental/resctl-demo) using cursive. First of all, cursive was a joy to learn and use and the project wouldn't have been possible without cursive. Thank you so much.
Here are some ideas I had while working on it, some of which I'm sure is from me not knowing what I'm doing:
# Colors
I couldn't figure out how Rgb colors are mapped to terminal colors. The color values will get applied with high variance depending on the terminal configuration. e.g. gnome-terminal + tmux would yield one set of colors but the colors would change without tmux in the middle. If I keep tweaking colors, it'd change syntax highlighting colors in emacs in a different tmux pane too, so I suppose shared palette is involved but it's all a black magic to me. This posed a bit of challenge because I was getting wildly different brightness of a color depending on the terminal type. I read about true color support in terminals but couldn't figure out how to detect or support it.
# Focus and scrolling in `LinearLayout::vertical()`
resctl-demo has an interactive document pane on the right which is a vertical `LinearLayout` containing `TextView`s, `Button`s and `Checkbox`s and `SliderView`s. PgUp/Down and arrow up/down navigation generally works but the focus position can be outside the current viewable area and the behavior becomes a bit jarring. ie. if I scroll up so that the focus is way below in the doc and then press arrow-down, the view will jump right to where the focus now is. I worked around this by adding dummy buttons between paragraph but it'd be really great if there's an option to keep focus within the current viewable area.
# Focus management / key-binding
I'm sure this is doable but I couldn't figure out how to block some elements from getting focus. There are two small scrollable areas left to the main doc area and they would get focus if the user presses left arrow (which can happen quite a bit when the user is interacting with a slider) which can get pretty confusing. It'd be great if I could e.g. restrict pane-jumping to tab and focus navigation in the pane to arrows.
# Borderless `Panel`
When `g` is pressed in resctl-demo, the app switches to graph view. I tried to get the graph view replace the content portion (lower 3/4 of the interface) while leaving the top status portion unchanged. I couldn't find a way to draw the graphs without extra `Panel` boundaries. I wonder whether borderless `Panel`s can be useful.
# `call_on_name()` on multiple targets
The doc pane can have, e.g., multiple sliders for the same control value. When the value changes, all have to change together. I worked around by assigning different names to them but it could be useful to be able to look up and call on multiple targets which share the same name.
# LogViewer using `TextView`
`TextView` supports replacing whole and appending but not trimming. For the log viewer, I'm keeping replacing the whole content whenever the content changes which isn't optimal. It'd be cool to have a way to trim content from `TextView`.
Contributor guide
Assessment
This issue has not been assessed yet.