no_std tracking issue

[orhun]

I gave it a spin on making several widgets no_std and sharing my findings here for proceeding with implementation after Ratatui 0.30 is out.

Workspace dependencies

• ratatui (0.30) -> std feature should be disabled.
• derive_builder -> std feature should be disabled and alloc should be enabled.
• strum -> std feature should be disabled.
• itertools -> use_std feature should be disabled.

tui-big-text

• font8x8 -> std feature should be disabled.

tui-bar-graph

• colorgrad does not support no_std yet.
  • Support no_std environments mazznoer/csscolorparser-rs#31
  • Support no_std environments mazznoer/colorgrad-rs#18

TODO: investigate the other crates

---

Additonally, #![no_std] indicator should be added to lib.rs for each crate.

[orhun]

tui-bar-graph is ready to be no_std'fied I think. I'm gonna do that when I'm working on Tuitar again, sometime later.

[joshka]

Codex no_std audit findings from a fresh pass over the widget crates.

What I checked:

• manifest-level deps/features for each tui-* crate
• obvious std:: usage in library sources
• spot verification with cargo check on some library targets using --no-default-features where applicable

Findings:

• tui-bar-graph

  • This one is in good shape now.
  • colorgrad can be used with default-features = false.
  • strum/std can be modeled behind a crate std feature instead of relying on transitive feature unification.
  • The interactive example is the main std consumer.

• tui-popup

  • Strong candidate for no_std.
  • It already has default = [] and cargo check -p tui-popup --lib --no-default-features passes.
  • Remaining std usage in library code looks trivial:
    • tui-popup/src/known_size_wrapper.rs: use std::fmt::Debug;
    • tui-popup/src/popup.rs: use std::fmt;
  • Those should be replaceable with core::fmt.

• tui-scrollbar

  • Also a strong candidate for no_std.
  • It already has default = [] and cargo check -p tui-scrollbar --lib --no-default-features passes.
  • Remaining std usage in library code looks trivial:
    • tui-scrollbar/src/metrics.rs: use std::ops::Range;
  • That should be replaceable with core::ops::Range.

• tui-scrollview

  • Looks like a good candidate.
  • I did not find meaningful std usage in library code; the obvious std reference is in docs (use std::iter;).
  • cargo check -p tui-scrollview --lib passes cleanly.
  • This one may mostly need #![no_std], extern crate alloc if needed, and a doc/example pass.

• tui-cards

  • Looks feasible with some cleanup.
  • Library code uses std::iter::zip in tui-cards/src/lib.rs, which should be replaceable with core::iter::zip.
  • color-eyre is listed in normal dependencies but appears to be used only by examples, so it likely belongs in dev-dependencies.
  • itertools is also in normal dependencies, but I did not find library usage in this pass.
  • strum is a real library dependency here.

• tui-qrcode

  • Looks feasible.
  • qrcode is already configured with default-features = false.
  • I did not find library std usage in the crate implementation.
  • color-eyre appears to be an example/doc dependency rather than a library dependency, so it likely belongs in dev-dependencies.

• tui-box-text

  • Less trivial.
  • Library code currently uses:
    • std::collections::HashMap
    • std::sync::LazyLock
    • std::iter::zip
  • This crate probably can be made no_std, but it needs a different strategy for the static character table rather than just manifest cleanup.
  • color-eyre is also in normal dependencies but appears example-only.

• tui-prompts

  • Probably not a good near-term no_std candidate.
  • It has a hard library dependency on crossterm.
  • Library code uses std directly in multiple places, e.g. tui-prompts/src/text_prompt.rs and tui-prompts/src/text_state.rs.
  • This crate looks std-bound by design today.

• tui-big-text

  • Already #![no_std].
  • This crate is the clearest reference point for how a no_std-ready widget crate looks in this repo.

Suggested next targets, in order:

1. tui-popup
2. tui-scrollbar
3. tui-scrollview
4. tui-cards / tui-qrcode dependency cleanup
5. tui-box-text as a more involved follow-up

One meta-finding: there are a few crates where color-eyre is still in [dependencies] even though it appears to be used only in examples/docs. Those are good low-risk cleanup candidates regardless of whether full no_std work happens immediately.

[chunix64]

tui-widgets/tui-big-text/src/big_text.rs

Line 68 in 83d2ad2

pub lines: Vec<Line<'a>>,

Heapless instead std::alloc::vec::Vec?