TL;DR; Is it correct that:

• the style of the contained paragraph should set the style of its surrounding block.
• the style set in the block (via block.style) sets the style for the blank space in the para even if the para has its own style set.

If I have a paragraph with a block around it then there are 4 combinations of setting styles for the text and box

  para         block
  -------      ------- 
  default     default
  explicit     default  
  default     explicit
  explicit     explicit      

by default I mean Style::default by explicit i mean say Style::default().bg(Color::Red).fg(Color::Yellow)

I used

• Style::default().bg(Color::Red).fg(Color::Yellow) for the block in my tests (setting block.border_style)
• Style::default().bg(Color::Blue).fg(Color::Green) for the paragraph

In a modified version of the paragraph sample app. (source below)

My expectation was a follows (for each combo listed above)

• white text on black everywhere
• green on blue text in a white on black box
• white on black text in a yellow on red box
• green on blue text in a yellow on red box

What I get is

I also ran the same code with block.style instead of block.border_style. Nothing in the docs explains the difference between them. So I wanted to see what happened

This seems to be suggesting that block.style is intended to set the overall style of the para/block combo (para inherits from block), whereas block.border_style only sets the stye of the block. Fine.

But note that in the second case of both screen shots the para style has overriden the default of the block. This is a surprise

Also note the odd fact that although the para is explicity set to blue on green in the last case (of the last screen shot) the style set in the block style 'wins' in the 'blank' space

are these 2 intended behaviors?

I also tried with styled text rather that styling the paragraph (para always set to Style::default)

(There are only 2 combos now since the para style is always set to default but the text is set to white on blue)

Note the big difference for the second one. The style of the text is not propagated to the containing block.

and for completeness sake , style text with the block style set via block.border_style

here is the modified code of the paragraph sample

    let size = f.size();

    // Words made "loooong" to demonstrate line breaking.
    let s = "Veeeeeeeeeeeeeeeery    loooooooooooooooooong   striiiiiiiiiiiiiiiiiiiiiiiiiing.   ";
    let mut long_line = s.repeat(usize::from(size.width) / s.len() + 4);
    long_line.push('\n');

    //   let block = Block::default().style(Style::default()); //.bg(Color::White).fg(Color::Black));
    // f.render_widget(block, size);

    let chunks = Layout::default()
        .direction(Direction::Vertical)
        .margin(5)
        .constraints(
            [
                Constraint::Percentage(25),
                Constraint::Percentage(25),
                Constraint::Percentage(25),
                Constraint::Percentage(25),
            ]
            .as_ref(),
        )
        .split(size);

    let text = vec![Spans::from("This is a line ")];

    let create_block = |title, dflt| {
        Block::default()
            .borders(Borders::ALL)
            .title(Span::styled(
                title,
                Style::default().add_modifier(Modifier::BOLD),
            ))
            .border_style(if dflt {
                Style::default()
            } else {
                Style::default().bg(Color::Red).fg(Color::Yellow)
            })
    };

    let paragraph = Paragraph::new(text.clone())
        .style(Style::default())
        .block(create_block("dflt dflt", true))
        .alignment(Alignment::Left);
    f.render_widget(paragraph, chunks[0]);

    let paragraph = Paragraph::new(text.clone())
        .style(Style::default().bg(Color::Blue).fg(Color::Green))
        .block(create_block("para = Gr/Bl bl = dflt", true))
        .alignment(Alignment::Left);
    f.render_widget(paragraph, chunks[1]);
    let paragraph = Paragraph::new(text.clone())
        .style(Style::default())
        .block(create_block("para = dflt, block = Y/red", false))
        .alignment(Alignment::Left);
    f.render_widget(paragraph, chunks[2]);
    let paragraph = Paragraph::new(text.clone())
        .style(Style::default().bg(Color::Blue).fg(Color::Green))
        .block(create_block("Para = b/g block = y/red ", false))
        .alignment(Alignment::Left);
    f.render_widget(paragraph, chunks[3]);
}

Environment

Add a description of the systems where you are observing the issue. For example:

• OS: Windows
• Terminal Emulator: windows terminal
• Font: ?
• Crate version: 0.20.1 (cloned current head)
• Backend: crossterm

Why do I care about ths. Because I am writing a widget that greys out a paragraphs text temporarily. If I do that when the surrounding block is set to Style::default then it gets greyed out too. And there is no way for me to inspect the block to look at its style (there is no get_style method)

originally taken from https://github.com/fdehau/tui-rs/pull/552.

Updates Viewport type, making it an enum with Fullscreen, Inline and Fixed views. Inline(_) includes the height of the inline screen.

Adds an insert_before method that can write permanent lines above the inline tui. Intended usecase is like yarn install, where there would be multiple updating elements at the bottom of the screen, and then 'xxx installed' would be permanent logs above the updating elements.

I've tried to minimise the breaking changes from the original PR, but there's still a breaking change in the Backend trait. In theory I can add some default methods to make it not a breaking change

(CC @pdecat, https://github.com/ellie/atuin/pull/648)

Upstream: #688

Description

Fixes issue #680. Handles the case where a list item is created with an empty string, which is not split by the lines iterator.

Testing guidelines

New test can be ran with cargo test

Checklist

• [x] I have read the contributing guidelines.
• [x] I have added relevant tests.
• [x] I have documented all new additions.

Upstream: #669

Description

Before you could only put the title on the top row of a block. Now you can put it on the bottom row! Revolutionary.

In the future, implementing an option for both a bottom and top title is possible, but seems unnecessary considering you could just manually have a Layout and do the work yourself at that point, and having support for title wizardry seems pointless. The farthest you could go is having an option to actually move the title everywhere; it's an easy extension and seems like something that would normally be built-in. Hence here it is; you can do top and bottom, left right and center.

Testing guidelines

When creating a Block with, say, Block::default().title(), slap on a .title_on_bottom(). Check tests/widget_block.rs for the tests, which are just a copy of the alignment tests.

Checklist

• [x] I have read the contributing guidelines.
• [x] I have added relevant tests.
• [x] I have documented all new additions.

Description

The table widget example is potentially misguiding users on the crossterm Events API. The table widget example uses the KeyCode enum in crossterm without filtering for the KeyEventKind::Press, which leads in events being doubled when pressing keys. It isn't a bug per se, I just don't think that was the behavior that was intended from the snippet.

line 108-115 in this file for the exact part

Upstream: #677

Description

It is a PR just to resolve issue #352

Add a few lines to explain how to define the coordinates

Testing guidelines

Just test it using VS Code

Checklist

• [X] I have read the contributing guidelines.
• [X] I have added relevant tests.
• [X] I have documented all new additions.

First of all, thank you for making this project revive. I'm suggesting to enable the discussions on this repository. Indeed, people may want to ask questions, share news of this project, and perhaps announce that the original owner came back. Well, it will be a great opportunity to exchange about this project.

Upstream: #689

Description

Testing guidelines

I checked all examples by cargo run --example {example-name} and confirmed they work on iTerm2 on my Mac machine.

Checklist

• [x] I have read the contributing guidelines.
• [x] I have added relevant tests. (Since this PR just upgrading existing dependency, no tests need to be added)
• [x] I have documented all new additions.

Description

crossterm v0.26.0 was released recently. And some people are starting to use the latest version. Since this crate requires crossterm 0.25, both 0.25 and 0.26 are mixed in user's project when the user depends on crossterm directly. I actually saw an issue around this in my tui-textarea project: https://github.com/rhysd/tui-textarea/issues/9

The best way to solve the issue is to follow the latest crossterm version by tui crate. I checked the release note and tui crate. Breaking changes seem not relevant to tui crate.

This is a breaking change due to MSRV bump from 1.56 to 1.58. crossterm 0.26 is using inline format arguments feature and it requires 1.58.

Upstream: #585

Main changes

I found that the current implementation of Layout was very heavy on allocations and clones, especially considering you're expected to use it plus the split() function every frame. So, I made some changes to allow Layout to work more on the stack.

This is what I changed Layout to

#[derive(Debug, Clone, PartialEq, Eq, Hash)]
pub struct Layout<'a> {
    direction: Direction,
    margin: Margin,
    constraints: &'a [Constraint],
    /// Whether the last chunk of the computed layout should be expanded to fill the available
    /// space.
    expand_to_fill: bool,
}

This replaces the constraints field with a reference to a slice, instead of a Vec<Constraint>. Considering that most implementations using Layout use static arrays anyway, this seemed like a no brainer, until I tried to use the LAYOUT_CAHCE. It is impossible to store this new Layout inside of the LAYOUT_CACHE because that would require that you borrow the given Layout for 'static. My solution to the problem was only storing the hash of the Layout into the cache as opposed to moving the entire Layout.

macro_rules! hash_layout {
    ($self:expr, $area:expr) => {{
        let mut to_hash = ahash::AHasher::default();
        $area.hash(&mut to_hash);
        $self.margin.hash(&mut to_hash);
        $self.expand_to_fill.hash(&mut to_hash);
        $self.direction.hash(&mut to_hash);
        $self.constraints.iter().copied().for_each(|f| match f {
            Constraint::Max(max) => to_hash.write_u16(max),
            Constraint::Min(min) => to_hash.write_u16(min),
            Constraint::Ratio(left, right) => {
                to_hash.write_u32(left);
                to_hash.write_u32(right);
            }
            Constraint::Length(length) => to_hash.write_u16(length),
            Constraint::Percentage(percentage) => to_hash.write_u16(percentage),
        });
        to_hash.finish()
    }};
}

#[derive(Clone, Copy)]
#[repr(transparent)]
struct CustomHash(u64);

impl Default for CustomHash {
    #[inline]
    fn default() -> Self {
        Self(0)
    }
}

impl std::hash::Hasher for CustomHash {
    #[inline]
    fn finish(&self) -> u64 {
        self.0
    }

    #[inline]
    fn write(&mut self, _: &[u8]) {
        panic!("unsupported operation");
    }

    #[inline]
    fn write_u64(&mut self, i: u64) {
        self.0 = i;
    }
}

thread_local! {
    static LAYOUT_CACHE: RefCell<HashMap<u64, Vec<Rect>, BuildHasherDefault<CustomHash>>> = RefCell::new(HashMap::default());
}

pub fn split(&self, area: Rect) -> Vec<Rect> {
    // TODO: Maybe use a fixed size cache ?
    LAYOUT_CACHE.with(|c| {
        c.borrow_mut()
            .entry(hash_layout!(self, area))
            .or_insert_with(|| split(area, self))
            .clone()
    })
}

This is the code I used for storing the layout. Here is a breakdown

• First I create a hasher using ahash, It's not critical that ahash be the hashing algorithm (the default hasher works as well). However, considering how often the split() function will be run, I think it's worth the sacrifice of one extra dependency.
• After creating the hasher, I feed it the area parameter, and then each field of the Layout one by one. cargo +nightly bench insisted that this was faster than simply running self.hash(&mut to_hash);
• After computing the hash of area + self, I use the final value as the final key into the LAYOUT_CAHCE.
• Because LAYOUT_CACHE uses CustomHash as it's RandomState, the hash computed by ahash is simply passed through and no further hashing is done. There's no point in hashing a hash.
• Finally, the resulting Vec<Rect> is either grabbed from the LAYOUT_CACHE or computed, and then cloned to bypass the reference created by the HashMap

Benchmarks

I did some benchmarks to see just how much my changes effected performance. This was my benchmark

#[bench]
fn bench_vertical_split_by_height(b: &mut test::Bencher) {
    let target = Rect {
        x: 2,
        y: 2,
        width: 10,
        height: 10,
    };

    let layout = Layout::default()
        .direction(Direction::Vertical)
        .constraints(
            [
                Constraint::Percentage(10),
                Constraint::Max(5),
                Constraint::Min(1),
            ]
            .as_ref(),
        );

    b.iter(|| layout.split(target));
}

When I benchmarked the original implementation and mine, these were my results. (top one is my implementation).

test layout::tests::bench_vertical_split_by_height ... bench:          89 ns/iter (+/- 5)
test layout::tests::bench_vertical_split_by_height ... bench:         243 ns/iter (+/- 2)

My implementation seems to be ~3x faster than the original implementation.

Swapping out ahash with the default hasher (std::collections::hash_map::DefaultHasher::default()) gave me this result

test layout::tests::bench_vertical_split_by_height ... bench:         148 ns/iter (+/- 10)

Smaller changes

I noticed that most of the methods inside of this module (layout) were very simple and small, so I made them const and #[inline]ed them.

Pre-requisites

All of my changes passed the unit tests and ran the examples.

Thanks for considering my PR, - StratusFearMe21

Fixes https://github.com/tui-rs-revival/ratatui/issues/82

When drawing a vertical line on a canvas, using Marker::Block would draw a gap in between each line. This is because the default block character was a half bar. This changes the default block character to a full block, and adds a new marker type Marker::Bar to replace the current Marker::Block.

BREAKING CHANGE: Marker::Block now uses a full block character, and Marker::Bar is the new half block character.

• Adds tests for each Marker in the canvas widget.
• Adds marker to the canvas example to show the difference between the marker types.

Hi I saw the user_input example was already updated to work on windows but I just did the rest of them that use input other than quit.

Also added a hack in panic.rs because on windows/powershell a release event is sent from when you originally press enter to cargo run. No more double presses now either.

Fix https://github.com/tui-rs-revival/ratatui/issues/120

Edit: I just looked at the conventional commit thing and it's just a fix, you can merge this now

Problem

There might be some time gaps between new releases so the users cannot test/use the latest functionality without using ratatui as a git dependency in Cargo.toml which makes the crate unpublishable on crates.io. (crates.io doesn't accept git dependencies)

See what atuin did recently as a workaround: https://github.com/ellie/atuin/commit/a515b06bcb556c1be2d0fc3095cd778d413fe40d

Solution

Create automated nightly releases every week or so. ratatui can be used as e.g. version = "nightly-2023-04-21" afterwards.

Alternatives

Just plan things out and release more frequently.

Additional context

None.

We need comments/thoughts on this.

Problem

In my projects I sometimes need a conversion like this:

"black" => TuiColor::Black,
"red" => TuiColor::Red,
"green" => TuiColor::Green,

Solution

Implement FromStr for ratatui::style::Color.

An example can be found here.

In the example, I used rgb crate for converting HEX values to Color as well. Since it introduces a new dependency, I'm not sure if we should do that as well.

Alternatives

None.

Additional context

I also did something like this in the past: https://github.com/orhun/kmon/blob/66f27006fed614c048469b2511b600d07c8912d6/src/style.rs#L110-L152

Description

When I execute one of the example code from your documentation, it prints random bytes on exit.

To Reproduce

use std::{io, thread, time::Duration};
use ratatui::{
    backend::CrosstermBackend,
    widgets::{Widget, Block, Borders},
    layout::{Layout, Constraint, Direction},
    Terminal
};
use crossterm::{
    event::{self, DisableMouseCapture, EnableMouseCapture, Event, KeyCode},
    execute,
    terminal::{disable_raw_mode, enable_raw_mode, EnterAlternateScreen, LeaveAlternateScreen},
};

fn main() -> Result<(), io::Error> {
    // setup terminal
    enable_raw_mode()?;
    let mut stdout = io::stdout();
    execute!(stdout, EnterAlternateScreen, EnableMouseCapture)?;
    let backend = CrosstermBackend::new(stdout);
    let mut terminal = Terminal::new(backend)?;

    terminal.draw(|f| {
        let size = f.size();
        let block = Block::default()
            .title("Block")
            .borders(Borders::ALL);
        f.render_widget(block, size);
    })?;

    thread::sleep(Duration::from_millis(5000));

    // restore terminal
    disable_raw_mode()?;
    execute!(
        terminal.backend_mut(),
        LeaveAlternateScreen,
        DisableMouseCapture
    )?;
    terminal.show_cursor()?;

    Ok(())
}

Expected behavior

To not print any byte to command line

Screenshots

Environment

• OS: Fedora 36
• Terminal Emulator: GNOME Terminal
• Font: Monospace
• Crate version: 0.20.1
• Backend: crossterm

Additional context

None

Problem

The Paragraph widget does not have a scroll bar.

Solution

Show the scroll bar for the Paragraph widget when the scroll is defined.

Alternatives

Additional context

A calendar widget that with some display options and styling for individual dates.

This widget displays the month provided to it in the constructor. (see docs and the example for more info).

One thing to note: This pulls in a new dependency, the time crate. Since this adds a dependency, it might be worth putting the widget behind a feature flag - I'm happy to do so if that's desired.

Problem

There might be performance issues/concerns about tui widgets and adding benchmarks is important to uncover them.

Solution

Add benches for widgets. See #22 for an example.

Alternatives

None.

Additional context

#22