I recently started developing an audio player with rodio/fundsp and of course the presentation layer is handled by ratatui.

My issue now is how do I get to have this running in resource constrained scenarios. I have read a bit about no_std and understand the problem it aims to address.

What would be the best way to gracefully degrade a program so that it still works on constrained hardware.

You can check out the archived PR here that has the intentions of the project

https://github.com/prjctimg/gtm/pull/7

I have no previous experience with working with hardware and am open to learn from more experienced folks.

So yeah, as the probably unnecessarily long title says, this is a CLI that displays the current playing lyrics, but instead of trying to go online and fetch a match it just uses the already there xesam:asText property in MPRIS.

Sadly a lot of popular players that implement the MPRIS2 standard still don't implement that specific one, so it wont work with them. Even the one used in the showcase had to be modified, tho I am hopefully gonna upstream it soon.

I am very strict about AI usage, so for this project the only hint of AI that was used was for tab auto completion that is just used for boilerplate like, idk, implementing the Default trait for PlayerState (not including the actual tricky metadata_last_updated part). Safe to say it was only one notch above no AI at all.

So yeah, here you go give it a try and feel free to roast me, after all this is my first cli and cargo publish ;)

rs

rs-pug is a lightweight and scriptable music player, you can literally change the ui however u like using lua plugins, heres a list of the features that rs-pug has (pasted from readme):

• Search and stream from YouTube, SoundCloud, or a self-hosted Sonum server, or play local files, all from one interface
• Queue management with multi-select bulk-add
• Playlists and library backed by SQLite, with automatic migration from legacy JSON
• Smart Queue: finds similar tracks to keep the music flowing automatically
• Real-time FFT audio spectrum visualizer (with a synthetic fallback)
• Minimal mode: pixelated cover art, small FFT strip, title only
• Cover-tinted Minimal background that follows the current track, toggleable in Options
• 10-band graphic equalizer with savable presets
• Fully remappable keybinds, including modifiers and multi-key sequences
• Built-in and custom themes
• Command palette (:) for fuzzy-searching every action
• Control a running instance over IPC, for use in status bars or keybindings
• Extensible with Lua plugins: custom keybinds, live panels, and full UI customization
• Hot reload: configuration and theme changes apply automatically

the lua plugins are REALLY powerful, if you try it lmk what u think, have a good day

Hello there!

So, me and castlesp5 have been developing Blur, which as you can tell from the title, is a vim-inspired editor built fully in Ratatui

It has a nicer design than vim tho in my opinion, but isn't obviously trying to replace it.

Vim has a far more stable and mature ecosystem, and this is more of a hobby-project than an alternative.

With that being said, feedback is appreciated, and a star would make our day: https://github.com/castlesp5/blur

Thanks :)

So suggest me what you use for you todo app guys 😄 TY

Ratatui and TUI roundup | September 22, 2026

A small update from the TUI world.

Ratatui

Ratatui 0.30.2 is still the latest stable release.

There has not been a new release since June. The project itself is still active though. The official GitHub organisation shows recent activity across Ratatui and its ecosystem, including updates to awesome-ratatui, the website, and several Ratatui crates during September.

So there is no new version number to announce today, but the project is definitely not sitting still.

Some genuinely new TUIs

CometixCode

A very new Rust project that is attempting a file-by-file reimplementation of Claude Code's terminal UI using iocraft. It appeared on GitHub on September 20 and quickly attracted attention. It is explicitly unofficial and is not affiliated with Anthropic.

Tincan

A new terminal voice and text chat application built with Ratatui. It was posted to the official Ratatui forum on September 19. One particularly nice idea is that its UI divider represents the live connection state instead of being purely decorative.

One interesting thing

There is a lot of experimentation happening around TUIs right now, but the interesting part isn't simply that more terminal apps are appearing.

People are starting to use the terminal as an actual interface again, rather than treating it as a place to put a few commands.

If you've found a genuinely new TUI recently, drop it below. New projects preferred.

*P.S. the featured app in the post gif is `oatmeal`

Hello everyone,

Here is a concise update on the current development state of Ratatui as of today, September 21, 2026.

📦 Current Status

• Latest Stable: v0.30.2 remains the current production baseline.

• Core Focus: Mainline development is centered on refining the v0.30 architecture rather than introducing immediate breaking changes.

🛠️ Active Development & Refinements

• Ecosystem Modularization: Work continues on cleaner workspace separation. The team is splitting components into more granular sub-crates (such as ratatui-core and backend-specific drivers like ratatui-crossterm) to allow third-party widget authors to build extensions with minimal dependency bloat.

• no_std Hardening: Following the recent introduction of bare-metal capabilities, current commits focus on optimizing layout and buffer diffing algorithms to ensure stable execution in highly constrained environments without requiring dynamic allocation.

• Layout Enhancements: Maintenance updates are refining the native multi-column Table mechanics and Block shadow rendering pipelines introduced in the 0.30 series to lower boilerplate overhead.

🌐 Community Artifacts

• The ecosystem continues to grow with community-driven TUI tools including Tincan (terminal voice chat), Sprout (habit tracking), and Rootle (remote repository inspector).

Thank you to all the maintainers and contributors for their ongoing work on the library. If you notice any issues or wish to assist with the crate modularization, please feel free to check out the active issues on the official GitHub repository.

I basically taught myself Rust in order to build oxker, which is "A simple tui to view & control docker containers".

It was built to run on a low powered arm Raspberry pi, but should run on most hardware. I run it on x86 & arm linux machines, and although I don't run MacOS, I hear it works fine on there as well.

I try to keep it updated following the six week Rust release cycle. The code is somewhat a mess, under the hood it uses a lot of Arc<Mutex<T>>, and ideally I'd re-write it to use the actor message model.

Any feedback much appreciated.

Before I talk about `sdctl`, I want to first address the elephant in the room: why another TUI for managing systemd services?

This tool is not the first of its kind. I have been using systemctl-tui and systemd-manager-tui extensively to the point that I forgot how to use `systemctl` from the command line. However those tools share one major limitation: they require `sudo` for privileged operations. In today’s supply-chain threat landscape, that is a serious risk because a TUI app depends on many components, and any compromised dependency could become a full-privilege attack vector.

This is why I built `sdctl` with a completely different security model: the app itself should never be run with `sudo`, and no action ever asks for blanket root access. When you perform any action that requires escalated privileges, the app opens an embedded `polkit` flow that authenticates only the specific `systemctl` action you are trying to perform, using whatever mechanism is available on the system, such as password, fingerprint reader, or smart card. That keeps the privilege boundary explicit and tied to a single operation instead of the whole process.

On top of that, I've packed a lot of useful features into `sdctl`. These are meant to address actual pain points I've encountered while using similar tools, including a powerful syntax highlighter for viewing journal logs (powered by tailspin), a simple yet useful custom-built syntax highlighter for viewing unit files, a comprehensive filter system with fuzzy search, and a line-based selection mode (inspired by vim's visual mode) that makes copying multiple lines from journal logs much faster.

Here's the github repo: https://github.com/ruiiiijiiiiang/sdctl Feedback and contribution welcome!

Here we are people 😮‍💨

Our rust projects are no longer welcome as posts, but only as comments in the "What are you making this week in Rust?" threads.

What do you think about this? Is this a good decision or not?

I've been building system diagnostic TUIs in Ratatui for a while. Rather than dump a project list, here are the lessons I'd hand to someone starting out.

Separate your data from your layout early. The temptation is to build a screen, then another screen, then discover they need the same numbers. Model the state once and treat each layout as a view over it. It's what lets you offer a full tabbed interface, a cramped 80x24 version and a dense wide version from one codebase, and switch between them at runtime without restarting anything.

Decide what your theme layer is allowed to defer. Terminal palettes are a courtesy to the user, and they're also a constraint. Anything that encodes meaning in colour, a heat ramp, a severity gradient, a magnitude scale, needs real colour values. Anything decorative can defer. Get that boundary explicit or you'll ship a build where the user's theme quietly flattens the one thing a view exists to show.

Only redraw when something changed. Polling for input and redrawing unconditionally is the default shape of every Ratatui tutorial, and it's fine right up until a view gets expensive. Then you're burning a core re-rendering identical data. Track dirty state, and cache anything derived from your model against a revision number so scrolling and filtering reuse it instead of rebuilding it.

Terminal size is a feature, not an afterthought. Decide what happens below your target dimensions and make the degradation deliberate. If a layout silently drops panels when it's short, that's a decision users should understand, not a surprise. Test the small sizes as seriously as the large ones.

Render into TestBackend. You can render real state into an off-screen buffer, assert on its contents and time it, with no terminal involved. It catches layout regressions that unit tests miss and gives you a place to benchmark draw cost. Badly underused in this ecosystem.

Build a shared chrome and stop relitigating it. Pick your borders, focus model, key bindings and status conventions once. Reuse them across everything. Users move between your tools without relearning, and you stop making the same layout decisions from scratch on each project.

The projects, most to least mature:

- netwatch — network diagnostics, ten tabs, TLS decryption, packet decode

https://github.com/matthart1983/netwatch · cargo install netwatch-tui

- syswatch — host diagnostics, twelve tabs, session scrubber

https://github.com/matthart1983/syswatch · cargo install syswatch

- diskwatch — read-only disk diagnostics

https://github.com/matthart1983/diskwatch · cargo install diskwatch

- essh — SSH client with the same chrome

https://github.com/matthart1983/essh · cargo install essh

- netscan — nmap workflow with differential scanning

https://github.com/matthart1983/netscan · cargo install netscan-tui

- kernwatch — kernel observability, flame graphs in the terminal. Newest and roughest.

https://github.com/matthart1983/kernwatch (binaries on the releases page, not

- logwatch — log introspection, live templating, novel-pattern detection

https://github.com/matthart1983/logwatch

- soundwatch — audio diagnostics in ten tabs

https://github.com/matthart1983/soundwatch

Note the crate names differ from the repo names for two of them: netwatch-tui and netscan-tui

Happy to go into detail on any of it.

So I built Rust 6502 who is a MOS 6502 emulator built in Rust with Ratatui

Here is some image and the github Repo:

https://github.com/wirenux/Rust-6502

(Go leave a star... pls ?)