-
-
Notifications
You must be signed in to change notification settings - Fork 489
Description
Problem
Ratatui should have a clear vision regarding how we approach problems and incorporate new features. I wanted to create this issue to share common ideas among maintainers and to clarify things for new contributors who would like to learn more about how things work. This will also help with maintenance, as it will serve as a guide for prioritization and hopefully get everyone on the same page. If you think this issue is missing any points or if you disagree with anything, feel free to discuss it below.
Solution
Like any other open-source project, we should have guiding principles that we follow when determining our next steps.
I would like to draw your attention to the two most important areas we should be focusing on as a TUI library.
1. Ease of Use
There is a fine line between allowing customizations and making something difficult enough to create a frustrating development experience. Right now, I feel like we are standing in the middle, which can be further improved by addressing the following usability-related issues in the long term:
- WidgetRef / StatefulWidgetRef tracking issue #1287
- RFC: Design of Scrollable Widgets #174
- RFC: Text Wrapping Design #293
- sophacles/extra-widgets - StyledList and Macros. #118
- feat(terminal): Add ratatui::init() and restore() methods #1289 (abstraction over the backends + reducing the boilerplate)
- Simplify the example code, make them consistent to make it easier to read / write the relevant bits.
- Embeddable/scrollable/input widgets. (see ratatui-widgets)
- Event loop / stateful widgets (see rat-salsa)
These and other universally useful issues should be prioritized in development.
2. Visual Appeal
What's a TUI library without a shiny UI?
We want to draw more attention to Ratatui by making it prettier, and I believe this can be achieved by:
- Making the examples look more polished.
- Allowing widget customization, such as in Support additional styles for the List widget #1168, Support a way to collapse borders in layout #605 and Allow the Inline ViewPort to be resized #984.
- Drawing inspiration from other TUI libraries (e.g., Textual, Bubbletea).
FAQ
Performance improvements
The current state of the library is not focused around zero allocations or generating the fastest LLVM IR. We take the performance into account while adding new features as long as that are aligned with an actual problem in a real application.
We are willing to make meaningful performance improvements if benchmarks show they are valuable. However, for smaller performance improvements, we will evaluate them on a case-by-case basis, considering factors such as maintainability and potential breakage.
Breaking changes
We may need to consider breaking changes as we explore these improvements, as they could add significant value in the long term. However, making changing an existing API that would impact large amounts of users is not actionable unless it is really useful.
What are the next steps?
We should break down these larger goals into smaller, actionable tasks in a roadmap, ideally with some milestones as well, so we know what to do and when to do it next.
Feel free to edit this issue for revisions.