ratatui-core

We are excited to announce the new version of ratatui - a Rust library that's all about cooking up TUIs 👨‍🍳🐀

✨ Release highlights: https://ratatui.rs/highlights/v0302/

⚠️ List of breaking changes can be found here.

Features

• 90639c1 (uncategorized) Add Termina backend by @joshka in #2561

  Summary

  • add the ratatui-termina backend crate using the published termina
    crate
  • expose the backend through the termina feature and Ratatui
    prelude/backend re-exports
  • add a small Termina event-loop example and wire the backend into CI,
    xtask, README generation, and docs

  Refs #1784

  Validation

  • cargo +nightly fmt
  • cargo check -p ratatui-termina --all-features --all-targets
  • cargo check -p ratatui --no-default-features --features termina
  • cargo check -p xtask
  • cargo check -p release-header
  • cargo xtask check-backend termina
  • cargo xtask test-backend termina
  • cargo xtask rdme --check
  • markdownlint-cli2 ARCHITECTURE.md ratatui-termina/README.md .github/ISSUE_TEMPLATE/bug_report.md

  ---

Bug Fixes

• fce3c80 (widgets) Require thread-safe shadow effects by @joshka in #2584

  Summary

  • require custom shadow effects to preserve the auto traits expected by
    Block-backed widgets
  • document the CellEffect auto-trait contract
  • add a public widget regression test for the affected ratatui::widgets
    re-exports

  Fixes #2583

  ---

• e306ce6 (buffer) Create updates for "uncovered" cells by @benjajaja in #2587

  When a wide cell from the previous buffer is replaced by a short/normal
  cell, the trailing cell does not get an update if its content does not
  change. But if the wide cell has a background (or other) style, the
  terminal did render the trailing cell with that style.

  Force trailing cells to update if background, underline, or modifiers
  are different than the wide cell. We can ignore foreground.

  Fixes #2585 (see that for the detailed visual reports)

• 81e667f (scrollbar) Keep a large thumb within the track at the end by @satyakwok in #2594

  Closes #2582.

  Problem

  When the content is shorter than the viewport, the thumb is large
  relative to the track. With the position at the end, part_lengths
  clamped thumb_start to track_length - 1 while thumb_length was
  clamped independently to [1, track_length], so thumb_start + thumb_length could exceed track_length.

  bar_symbols lays out begin + track_start + thumb + track_end + end
  and zips it against the cells of the area. When the thumb overruns the
  track, track_end saturates to 0 but the thumb still emits more cells
  than the track can hold, so the trailing end symbol is pushed past the
  end of the area. The last visible cell ends up being a thumb (█) where
  the end arrow (▼) should be.

  Concretely, for the issue's repro (VerticalRight, content_length = 9, position = 8, height 24): track is 22, thumb_length = 17,
  thumb_start = 6, and 6 + 17 = 23 > 22.

  This is a regression from v0.30.0, where thumb_length was derived as
  thumb_end - thumb_start and therefore always fit within the track.

  Fix

  Clamp thumb_start to track_length - thumb_length (instead of
  track_length - 1) so the thumb always fits within the track and the
  end symbol is preserved.

  Test

  Two regression tests, both fail on main and pass with the fix:

  • thumb_stays_within_track_for_large_thumb_at_end checks
    part_lengths directly with the issue's parameters — asserts
    thumb_start + thumb_length <= track_length and that the parts sum to
    the track length.
  • render_scrollbar_keeps_end_symbol_for_large_thumb renders the #2582
    case (both arrows, large thumb at the end) and asserts the end symbol is
    drawn rather than overwritten by a thumb cell.

  All existing scrollbar tests still pass.

Miscellaneous Tasks

• c75d778 (ci) Add cargo-udeps dependency check by @joshka in #2599

  Adds cargo xtask udeps and runs it from CI as a required job.

  This complements cargo-machete rather than replacing it. cargo-machete
  is a fast static source scan, which is why it missed the package-level
  unused deps fixed in #2598 when the same dependency names were still
  referenced by example crates. cargo-udeps compiles the workspace and
  checks rustc dep-info, so it can catch unused dependency declarations
  for the package being checked.

  To make the new job pass, this also removes the remaining true-positive
  unused dev-deps and records explicit cargo-udeps ignores for current
  false positives / intentional cases: ratatui-core critical-section,
  ratatui-crossterm's duplicate crossterm version feature shape, and
  ratatui-termwiz's doc-example-only ratatui dev-dependency.

  I searched existing issues and PRs for udeps / cargo-udeps / "cargo
  udeps". I did not find prior ratatui discussion about adopting
  cargo-udeps; the only hits were Dependabot PR bodies for
  taiki-e/install-action release notes mentioning cargo-udeps version
  updates, for example #1971, #2095, #2194, and #2522.

  Validation:- cargo xtask udeps

  • cargo xtask format --check

  ---

• 4a63d41 (uncategorized) Remove unused dependencies by @KikiKian in #2598

  Audit removes these dependencies that are not used:

  ratatui/Cargo.toml — Removed from [dev-dependencies]:

  • futures
  • rand_chacha
  • tokio
  • tracing
  • tracing-appender
  • tracing-subscriber

  ratatui-core/Cargo.toml — Moved from [dependencies] →
  [dev-dependencies]:

  • indoc

  ---

Continuous Integration

• 36854ef (uncategorized) Add auto-merge required gate by @joshka in #2596

  Summary

  This makes GitHub auto-merge usable for Ratatui PRs once maintainers are
  happy with the change but CI is still running.

  The workflow change adds a single aggregate required job to the main
  CI workflow. The repository now has auto-merge
  enabled
  and an ensure checks pass
  ruleset
  that requires that required status context on main.

  Why

  Without a required status context, GitHub's auto-merge button is not
  useful for the maintainer flow we want. The goal is to let a maintainer
  review a PR, decide it is ready, click auto-merge, and move on without
  coming back later just to check whether the remaining jobs finished.

  This does not relax the merge policy. GitHub's own auto-merge behavior
  is to merge only after all required reviews and required status checks
  are satisfied. This change gives GitHub a stable required status to wait
  on automatically.

  Precedent

  I have been using this same auto-merge pattern in
  ratatui/tui-widgets, where
  it has worked well for the intended maintainer flow: once a PR looks
  ready, I can enable auto-merge and let GitHub merge it after the
  remaining checks and review requirements are satisfied.

  How it works

  The new required job depends on the main CI jobs in
  .github/workflows/ci.yml and always runs after them. It fails if any
  required dependency fails, is cancelled, or is skipped.

  The repository ruleset requires only this aggregate required context
  instead of requiring every individual matrix job separately. That gives
  GitHub one stable status to wait on while preserving the existing CI
  coverage.

  Things to know

  • Auto-merge is opt-in per PR. Maintainers still choose when to click
    it.
  • It does not skip review requirements, status checks, labels, or any
    other protection rule.
  • A PR with auto-merge enabled can still show as blocked while checks or
    required reviews are pending. That is expected.
  • If something needs to merge normally, maintainers can still use the
    regular merge path or an allowed ruleset bypass. This is a convenience
    path, not a hard blocker.
  • Existing open PRs may need a rebase or synchronize event after this
    lands so they pick up the new required workflow job.
  • If a new required CI job is added later, it should be added to the
    required.needs list or it will not be represented by the aggregate
    gate.
  • Jobs that are intentionally allowed to fail should be handled
    carefully before adding them to required.needs, because skipped,
    cancelled, and failed dependencies make the aggregate fail.

  Current PR state

  Auto-merge is already enabled on this PR. If you approve it and the
  required checks pass, GitHub will squash-merge it automatically;
  approving it is enough to let the PR merge once the remaining
  requirements are satisfied.

  GitHub docs

  • Automatically merging a pull
    request
  • Managing auto-merge for pull requests in your
    repository
  • About
    rulesets
  • Require status checks to pass before
    merging
  • About status
    checks
  • Troubleshooting required status
    checks

  Validation

  • ruby -e 'require "yaml"; YAML.load_file(".github/workflows/ci.yml"); puts "ok"'
  • actionlint .github/workflows/ci.yml
  • Verified ratatui/ratatui has allow_auto_merge: true
  • Verified the active ensure checks pass ruleset requires status
    context required
  • Verified this PR has squash auto-merge enabled and is blocked pending
    checks/review

New Contributors

• @satyakwok made their first contribution in #2594
• @KikiKian made their first contribution in #2598

Full Changelog: ratatui-v0.30.1...ratatui-v0.30.2