joshka / tui-widgets

A collection of useful widgets for building terminal user interfaces using Ratatui

Ratatui-org

Ratatui

Ratatui-website

Ratatui related

bevy_ratatui

focusable

keybinding

pong-russh

ratatui-calloop

ratatui-widgets

tui-big-text

tui-brulee

tui-macros

tui-markdown

tui-popup

tui-prompts

tui-scrollview

Apps

ja

nitidus

tooters

xkcdwat

tui-widgets's Issues

Render big-text inside popup

Is it possible to render inside the popup SizedWrapper of your other library?

BTW I love your stuff!!

Possibility to render stateful widget inside popup

I want to render a stateful widget(The built-in widget list). But it appears that I can't pass the state through tui-popup.

Would it be possible to design an API to allow state to be passed through tui-popup to a inner stateful widget? Or should we change the API to make popup work more like a Block so that users could manually render whatever they want inside it?

Latest changelog / release notes are not properly updated

This was due to a combination of things going wrong. Full details in MarcoIeni/release-plz#1601
These need to be regenerated from the commits using git-cliff to be more accurate.

Fix tui-prompts test failures

---- text_prompt::tests::draw_no_wrap stdout ----
thread 'text_prompt::tests::draw_no_wrap' panicked at src/text_prompt.rs:383:9:
assertion `left == right` failed
  left: (16, 1)
 right: (16, 0)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- text_prompt::tests::draw_wrapped stdout ----
thread 'text_prompt::tests::draw_wrapped' panicked at src/text_prompt.rs:440:9:
assertion `left == right` failed
  left: (16, 1)
 right: (5, 1)


failures:
    text_prompt::tests::draw_no_wrap
    text_prompt::tests::draw_wrapped

Fixup changelog generation

There's some weirdness in the autogenerated changelogs that would be nice to clear up

tui-widgets/CHANGELOG.md

Lines 20 to 35 in a440b4e

	### ⚙️ Miscellaneous Tasks
	- Various fixes / clippy lints ([#6](https://github.com/joshka/tui-widgets/pull/6))
	<!-- generated by git-cliff -->
	# Changelog
	All notable changes to this project will be documented in this file.
	The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
	and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
	## [Unreleased]
	## [0.1.3](https://github.com/joshka/tui-widgets/compare/tui-widgets-v0.1.2...tui-widgets-v0.1.3) - 2024-07-24
	### Fixed

• go over the git-cliff settings and work out a good format for consistent generation based on the previous code
• check over the conventional / non-conventional commits to work out if stuff is missing
• check over the release-plz settings to work out if theres some conflict

Latest releases are versioned as minor but are actually major releases

This is a fun one.

TLDR: I can't upgrade to ratatu 0.28 just yet, but in order to defer that upgrade, I had to fix my Cargo.toml to say tui-prompts = "=0.3.20" instead of tui-prompts = "0.3.20". This was hard to diagnose, and I think ideally I shouldn't have had to care about this.

Concretely, the problem is that I can't update to ratatui 0.28 because a dependency I use, crokey, hasn't updated to it and still depends on 0.27. I had this in my Cargo.toml:

tui-prompts = "0.3.17"

...but blowing away my Cargo.lock and re-creating it broke my build because tui-prompts expressed its own ratatui 0.27 -> 0.28 upgrade using a compatible version change, instead of bumping its major version. My code, using ratatui 0.27, was using types incompatible with tui-prompts. In this build the only package using ratatui 0.28 was tui-prompts, and this upgrade happened automatically, because of the characterization of the release as a minor version bump.

The tui-prompts 0.3.21 release, which was a minor release, bumped its ratatui dependency to 0.28. Because tui-prompts uses ratatui APIs in its own API, this amounts to a major version bump, as evidenced by the build breaks I saw. I think tui-prompts version 0.3.21 should have been 0.4.0. This way, Cargo won't automatically upgrade past 0.3.20 to an incompatible version of tui-prompts.

I don't have a direct citation to docs that clearly state this as a best practice. There is https://doc.rust-lang.org/cargo/reference/semver.html, but this is broad and fairly loose recommendation, and doesn't talk specifically about crates that use APIs from other crates. I'm just deducing this from this experience, with a line of reasoning like:

1. I can't use tui-prompts without using ratatui and crossterm APIs with it.
2. I use multiple crates that use ratatui and crossterm APIs. As such, when I upgrade ratatui and crossterm, their upgrades need to be coordinated across all the crates.
3. If ratatui and/or crossterm have a major version bump, rust won't consider their types compabile. As such, a major version bump in these dependencies is a "major version" change to all code using their types in their public API surface.
4. The default recommendation is to specify versions with bare versions in Cargo.toml ("0.3.17"). By doing so, cargo will attempt to select compatible versions. This should be enough to prevent multiple versions of ratatui and crossterm from appearing in my "cargo tree" output.
5. Alternatively, tui-widget crates could take careful, and manual, notes of the APIs they use, and express version constraints that span major versions (e.g. tui-prompts could probably claim that it is compatible with both ratatui 0.27 and 0.28, and similar for crossterm). That would be a lot of finicky work, though.

(Incidentally, I also buy into the reasoning that semver is often a joke beacuse it is a human that is deciding what is "major" and what is "minor", and it is extremely easy for API breaks to leak into minor releases accidentally)

underline big text displays multiple lines

That how it looks

Pull in scrollview PR from tui-scrollview

joshka/tui-scrollview#29

by @s9tpepper