Describe the bug The table widget is panicking when it doesn't for the screen

Here is the stack trace thrown at https://github.com/kdash-rs/kdash/blob/main/src/ui/overview.rs#L262

thread '<unnamed>' panicked at 'Trying to access position outside the buffer: x=189, y=16, area=Rect { x: 0, y: 0, width: 189, height: 40 }', /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:217:9
   0: kdash::panic_hook
             at src/main.rs:57:46
   1: kdash::main::{{closure}}::{{closure}}
             at src/main.rs:76:5
   2: std::panicking::rust_panic_with_hook
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:581:17
   3: std::panicking::begin_panic_handler::{{closure}}
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:484:9
   4: std::sys_common::backtrace::__rust_end_short_backtrace
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/sys_common/backtrace.rs:153:18
   5: rust_begin_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:483:5
   6: std::panicking::begin_panic_fmt
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:437:5
   7: tui::buffer::Buffer::index_of
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:217:9
   8: tui::buffer::Buffer::get_mut
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:184:17
   9: tui::buffer::Buffer::set_style
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/buffer.rs:358:17
  10: tui::widgets::table::render_cell
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/widgets/table.rs:513:5
  11: <tui::widgets::table::Table as tui::widgets::StatefulWidget>::render
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/widgets/table.rs:440:17
  12: tui::terminal::Frame<B>::render_stateful_widget
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/terminal.rs:137:9
  13: kdash::ui::overview::draw_nodes
             at src/ui/overview.rs:304:5
  14: kdash::ui::overview::draw_active_context_tabs
             at src/ui/overview.rs:116:10
  15: kdash::ui::overview::draw_overview
             at src/ui/overview.rs:22:5
  16: kdash::ui::draw
             at src/ui/mod.rs:49:7
  17: kdash::start_ui::{{closure}}::{{closure}}
             at src/main.rs:179:23
  18: tui::terminal::Terminal<B>::draw
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tui-0.14.0/src/terminal.rs:259:9
  19: kdash::start_ui::{{closure}}
             at src/main.rs:179:5
  20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/mod.rs:80:19
  21: kdash::main::{{closure}}
             at src/main.rs:122:3
  22: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/future/mod.rs:80:19
  23: tokio::park::thread::CachedParkThread::block_on::{{closure}}
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/park/thread.rs:263:54
  24: tokio::coop::with_budget::{{closure}}
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/coop.rs:106:9
  25: std::thread::local::LocalKey<T>::try_with
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:272:16
  26: std::thread::local::LocalKey<T>::with
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/local.rs:248:9
  27: tokio::coop::with_budget
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/coop.rs:99:5
      tokio::coop::budget
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/coop.rs:76:5
      tokio::park::thread::CachedParkThread::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/park/thread.rs:263:31
  28: tokio::runtime::enter::Enter::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/runtime/enter.rs:151:13
  29: tokio::runtime::thread_pool::ThreadPool::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/runtime/thread_pool/mod.rs:71:9
  30: tokio::runtime::Runtime::block_on
             at /home/deepu/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-1.4.0/src/runtime/mod.rs:452:43
  31: kdash::main
             at src/main.rs:73:1
  32: core::ops::function::FnOnce::call_once
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
  33: std::sys_common::backtrace::__rust_begin_short_backtrace
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys_common/backtrace.rs:137:18
  34: std::rt::lang_start::{{closure}}
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:66:18
  35: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/core/src/ops/function.rs:259:13
      std::panicking::try::do_call
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:381:40
      std::panicking::try
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panicking.rs:345:19
      std::panic::catch_unwind
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/panic.rs:382:14
      std::rt::lang_start_internal
             at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/library/std/src/rt.rs:51:25
  36: std::rt::lang_start
             at /home/deepu/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/rt.rs:65:5
  37: main
  38: __libc_start_main
  39: _start
────────────────

To Reproduce

I couldnt reproduce this on a standalone setup as it seems to work fine with same data as in error case. Below are the table rows when error happened

vec![
                    "gke-hello-hipster-default-pool-cddd8f85-0t5r",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "950m",
                    "2828",
                    "15%",
                    "20%",
                    "6d23h",
                ],
                vec![
                    "gke-hello-hipster-default-pool-cddd8f85-9gzv",
                    "Ready",
                    "<none>",
                    "v1.18.16-gke.2100",
                    "7",
                    "900m",
                    "2820",
                    "20%",
                    "20%",
                    "6d23h",
                ],

So i'm unable to pinpoint whats going wrong here

Expected behavior Should not panick regardless of screen size

Desktop (please complete the following information):

• OS: Fedora 32. Kernel 5.11.10-100.fc32.x86_64
• Terminal Emulatoron Yakuake, Tilix, Konsole and VSCode terminal
• Font [Monospace]
• Crate version [0.14]
• Backend [crossterm]

This implements the idea I outlined in https://github.com/fdehau/tui-rs/issues/91#issuecomment-634998916:

can't Frame have a field like Option<(u16, u16)>, which is the cursor's desired position after drawing the frame? None means the cursor is hidden, Some with a position means the cursor is shown and is positioned at the given cell.

The implementation deviates from the idea in two ways.

First of all, Frame is moved into the drawing closure — there is no way for Terminal::draw() to examine frame's fields afterwards. This could be resolved in two ways:

1. make Terminal::draw() require FnOnce(&mut Frame<B>). This is very clean, but it's a breaking change, so I decided against that.

2. store that Option<(u16, u16)> in the Terminal itself, and make Frame just pass the calls through. That's a bit of a hack, because I don't think it's Terminal's responsibility to store this data; it's Frame's job to describe what has to be drawn and how.

The second option is a non-breaking change, so I went with that.

That decision led to the second deviation. Terminal already has an API for controlling the cursor: hide_cursor(), show_cursor(), set_cursor(). These calls have immediate effect on the terminal (modulo stdout buffering). This conflicts with the proposed API, and could be resolved in two ways:

1. make the old API non-public. This doesn't seem right to me, since Terminal is supposed to be a low-level wrapper around the backend.

2. make the new API opt-in. Up until the first call to Frame::set_desired_cursor_position(), calls to draw() don't affect cursor visibility, so the user is free to use Terminal::hide_cursor() and Terminal::show_cursor(). After the first call to the new API, however, the cursor position and visibility is always enforced after each Terminal::draw() call.

The first option is not viable, so I went with the second one.

I think that in the long term, tui-rs should change the signature of Terminal::draw(), to move all of this to Frame, and make Terminal a completely low-level thing again. If that's the plan, it might make sense to make the new API on Terminal non-public now, so people don't depend on what is going to be removed. @fdehau, I'm also okay with re-doing the PR to change the signature now, if you're ok with a breaking change.

When using Text::styled in a List or Table, the background color only affects the text. I believe it should affect the whole Row/Cell in which the text is in.

To Reproduce

let splits_list = splits.iter().map(|(txt)| {
    Text::styled(Cow::from(txt), 
        Style::default()
            .bg(Color::Red))
});
let mut splits_list = List::new(splits_list)
    .style(normal_style1);
f.render(&mut splits_list, chunks[0]);

Screenshots

Desktop:

• OS: Tested on [Linux Mint Cinnamon and Windows 10]
• Terminal Emulator [Gnome Terminal, Power Shell and Cmd]
• Font [Monospace and Consolas]
• Crate version [0.8]
• Backend [crossterm]

Thanks for the wonderful library! :heart:

Issue

I ran into some unexpected behaviour recently when I was attempting to print a paragraph with some indentation in wrapping mode – TUI was stripping the leading whitespace from my lines.

I've since discovered that this is an intentional behaviour, but that leaves me unable to print a paragraph like this:

MW Word of the Day                                                            
*verb*                                                                        
   1) to diffuse through or penetrate something                               
   2) to spread or diffuse through                                            
   3) to pass through the pores or interstices of

Changes

In this PR, I simply disabled this behaviour, as I feel it's more predicable.

The above paragraph now wraps as follows:

MW Word of the Day            
*verb*                        
   1) to diffuse through or   
penetrate something           
   2) to spread or diffuse    
through                       
   3) to pass through the     
pores or interstices of

Justification

Slightly funky? Perhaps, but much more predicable and arguably clearer than no indentation whatsoever.

Comparing to the current master TUI branch:

MW Word of the Day            
*verb*                        
1) to diffuse through or      
penetrate something           
2) to spread or diffuse       
through                       
3) to pass through the pores  
or interstices of 

The lack of indentation makes it hard to tell that those are distinct "bullet points". The user can always trim strings in their application, but can't re-add the spacing TUI strips.

Tests

I adapted one of the leading-space tests to test indentation is preserved, but the other two I removed. If you are curious, the output of the removed tests was:

---- widgets::reflow::test::line_composer_char_plus_lots_of_spaces stdout ----
thread 'widgets::reflow::test::line_composer_char_plus_lots_of_spaces' panicked at 'assertion failed: `(left == right)`
  left: `["a", "                    ", "                    ", "       "]`,
 right: `["a", ""]`', src/widgets/reflow.rs:401:9

---- widgets::reflow::test::line_composer_lots_of_spaces stdout ----
thread 'widgets::reflow::test::line_composer_lots_of_spaces' panicked at 'assertion failed: `(left == right)`
  left: `["                    ", "                    ", "                    ", "      "]`,
 right: `[""]`', src/widgets/reflow.rs:385:9

Are a load of lines filled by nothing but spaces useful? Probably not, but at least this gives the user the choice to keep or remove them. This new behaviour is also somewhat more in line with the LineTruncator which leaves the trailing whitespace.

Previously the highlight style (even if not present) overrode the row styles for a table and list:

With this change, if there is no highlight style defined, the selected item follows the style of the row:

When a highlight style is defined, it is merged with the data style:

This is now implemented on top of StyleDiff. The highlight_style and header_style are accepted through that. The basic style is still a normal Style as this should be the lowest priority style so there's nothing to patch that on top of.

I also wish I could have added DiffStyled variants to Text and Row, but that would have been a compatibility break. Maybe it should be considered for the next semver-major release?

There's also some overall improvements here in how styles get applied between highlight symbols, etc.

Describe the bug In order to prepare the pull request for the Clear-feature (https://github.com/fdehau/tui-rs/pull/244) I pulled in the master and realized that crossterm terminal sizing seems broken: (see screenshot)

The terminal seems to have a default size and not using up the actual terminal size. Also the resize events are not changing anything.

To Reproduce In my case (macOS) I only need to run the Crossterm-demo:

cargo run --example crossterm_demo --no-default-features --features="crossterm" --release -- -tick-rate 200

Expected behavior A clear and concise description of what you expected to happen.

Screenshots

Desktop (please complete the following information):

• OS: macos
• Terminal Emulator: iTerm2
• Crate version: master
• Backend: crossterm

Additional context This was working as intended in the previous release

Hi, I am the writer of Crossterm cross-platform terminal manipulation library. In a short time, I will launch a new version of my crate which has than support for user input. It will then have all the features that termion has but then crossplatform.

Interested? is there a place where I could contact you like discord or so?

Would love to try using tui, but when I run the demo it looks like it's not quite ready to use in Windows.

Here's running the crossterm_demo in Windows:

Is there a better way to get Windows support aside from crossterm? If not, are there any plans for making Windows supported?

I would like the option of building widgets with rounded corners given the unicode characters for this exist. I have tried to figure out how to implement that option but am having a difficult time figuring out the flow that leads to building a widget and where that option would be introduced. The below snippets may be confusing, so you can skip those and check https://github.com/stevensonmt/tui-rs/commit/db80ae911174cc388c10092e12a2713d7c8b24ab if that is easier.

In symbols::line I have this:

pub mod line {
    pub const TOP_RIGHT: &str = "┐";
    pub const TOP_RIGHT_ROUNDED: &str = "╮";
    pub const VERTICAL: &str = "│";
    pub const HORIZONTAL: &str = "─";
    pub const TOP_LEFT: &str = "┌";
    pub const TOP_LEFT_ROUNDED: &str = "╭";
    pub const BOTTOM_RIGHT: &str = "┘";
    pub const BOTTOM_RIGHT_ROUNDED: &str = "╯";
    pub const BOTTOM_LEFT: &str = "└";
    pub const BOTTOM_LEFT_ROUNDED: &str = "╰";
    pub const VERTICAL_LEFT: &str = "┤";
    pub const VERTICAL_RIGHT: &str = "├";
    pub const HORIZONTAL_DOWN: &str = "┬";
    pub const HORIZONTAL_UP: &str = "┴";
}

and for layout::Rect

pub struct Rect {
    pub x: u16,
    pub y: u16,
    pub width: u16,
    pub height: u16,
    pub rounded_corners: bool,
}

impl Default for Rect {
    fn default() -> Rect {
        Rect {
            x: 0,
            y: 0,
            width: 0,
            height: 0,
            rounded_corners: false,
        }
    }

and in widgets::block:

        // Corners
        if self.borders.contains(Borders::LEFT | Borders::TOP) {
            let top_left = match area.rounded_corners {
                true => line::TOP_LEFT_ROUNDED,
                _ => line::TOP_LEFT,
            };
            buf.get_mut(area.left(), area.top())
                .set_symbol(top_left)
                .set_style(self.border_style);
        }
        if self.borders.contains(Borders::RIGHT | Borders::TOP) {
            let top_right = match area.rounded_corners {
                true => line::TOP_RIGHT_ROUNDED,
                _ => line::TOP_RIGHT,
            };
            buf.get_mut(area.right() - 1, area.top())
                .set_symbol(top_right)
                .set_style(self.border_style);
        }
        if self.borders.contains(Borders::LEFT | Borders::BOTTOM) {
            let bottom_left = match area.rounded_corners {
                true => line::BOTTOM_LEFT_ROUNDED,
                _ => line::BOTTOM_LEFT,
            };
            buf.get_mut(area.left(), area.bottom() - 1)
                .set_symbol(bottom_left)
                .set_style(self.border_style);
        }
        if self.borders.contains(Borders::RIGHT | Borders::BOTTOM) {
            let bottom_right = match area.rounded_corners {
                true => line::BOTTOM_RIGHT_ROUNDED,
                _ => line::BOTTOM_RIGHT,
            };
            buf.get_mut(area.right() - 1, area.bottom() - 1)
                .set_symbol(bottom_right)
                .set_style(self.border_style);
        }

As I've dug into the rabbit hole of the build pattern I find that terminal_size() returns a rectangle (which seems a bit counter-intuitive to me as "size" implies just dimensions not shape). This seems to be the starting point so I've added a rounded_corners: bool field to the termion::TermionBackend struct and changed the size() method to:

    /// Return the size of the terminal
    fn size(&self) -> io::Result<Rect> {
        let terminal = termion::terminal_size()?;
        Ok(Rect::new(
            0,
            0,
            terminal.0,
            terminal.1,
            self.rounded_corners,
        ))
    }

By then adding appropriate boolean parameters to the termion_demo.rs and ui.rs files I have been able to compile the demo but the corners are still sharp not rounded. Any suggestions?

I noticed, and I hear from some other people that the input of the crossterm backend is not working correctly, especially talking about the crossterm demo example. The keys seem not to be recorded. I can have a look at this in a few days, but if there are people that can do that as well it will be appreciated.

Description

I added the following constraints to a new table. These aren't the final values I want, so they're just preliminary to see what it looks like:

                 .widths(&[
                      tui::layout::Constraint::Min(2),
                      tui::layout::Constraint::Max(20),
                      tui::layout::Constraint::Max(10), // Commit date (truncates time by default)
                  ])

I end up seeing this:

To Reproduce

The latest commit /w this problem in my application is at https://github.com/medwards/gitt/tree/buggy_table_constraints

You can also change examples/table.rs with the following patch:

index 846a55c..beda582 100644
--- a/examples/table.rs
+++ b/examples/table.rs
@@ -118,7 +118,7 @@ fn main() -> Result<(), Box<dyn Error>> {
                 .highlight_style(selected_style)
                 .highlight_symbol(">> ")
                 .widths(&[
-                    Constraint::Percentage(50),
+                    Constraint::Min(10),
                     Constraint::Length(30),
                     Constraint::Max(10),
                 ]);
diff --git a/src/text.rs b/src/text.rs
index 70a71d0..ae55981 100644
--- a/src/text.rs
+++ b/src/text.rs
@@ -183,13 +183,13 @@ impl<'a> Span<'a> {
 
 impl<'a> From<String> for Span<'a> {
     fn from(s: String) -> Span<'a> {
-        Span::raw(s)
+        Span::raw(s.replace("\r", "").replace("\n", ""))
     }
 }
 
 impl<'a> From<&'a str> for Span<'a> {
     fn from(s: &'a str) -> Span<'a> {
-        Span::raw(s)
+        Span::raw(s.replace("\r", "").replace("\n", ""))
     }
 }

And then:

$ cargo run --example table

Expected behavior

Minimally, I expected the column widths to remain the same if the rows and no other state change. In this case I expect there to be 30 characters spent for the right-most columns and whatever is left is used by the left-most column (ie Constraint::Min(n) means it should be at least n wide but will also use any remaining width available).

This might just be a docs snag, maybe Min means something else, but Constraint has no docs to explain otherwise.

Environment

• OS: Linux
• Terminal: gnome-terminal
• Font: Ubuntu Mono Regular
• Crate version: 0.14
• Backend: crossterm

Description

Add hncli, an Hacker News TUI reader, to the list of applications made with tui-rs. Thanks for the library, can help with maintenance if needed!

Testing guidelines

N/A

Checklist

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

Description

Add EDMA to tui-rs application list

Checklist

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

Description

confusion in dependencies in the example and what how to test or compile each binary or all in one go its just confusing for begineer. For example,if new dev wanted to test the demo in the example,they will most probably try copy the folder out.but they need the cargo to build the deps,so they will try copy the deps but the cargo.toml needs example folder to exist,so they copy the whole example folder

To Reproduce

Expected behavior

Screenshots

Environment

• OS:
• Terminal Emulator:
• Font:
• Crate version:
• Backend:

Additional context

Description

Add ruscode to list of projects using tui-rs. This crate had already published to crates.io.

Testing guidelines

Checklist

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

Problem

Hello ! I just noticed that i can't select multiple items in a Table, only a single item is allowed.

Solution

Implement code for allowing multiple selection of items in a Table. I see an open PR regarding this problem with List too, the work could be based on that with little modification.

Description

I am building an alternative to the watch command watchbind. I am using the widget List with Listitems. I am wondering why the example code

	let items = vec![
		ListItem::new("line one"),
		ListItem::new(""),
		ListItem::new("line four"),
	];
	let list = List::new(items)
		.style(Style::default().fg(Color::White))
		.highlight_style(Style::default().fg(Color::Black).bg(Color::White));
	f.render_stateful_widget(list, f.size(), &mut events.state);

does not render the second line, but the state obviously knows about it because I can scroll normally with j and k (which I programmed).

To Reproduce

Expected behavior

All lines should be visible in the output, even the empty lines.

Screenshots

On the left side is the output of watchbind -- git -h, on the right side git -h. As you can see, the empty lines are omitted on the left, which uses the tui List widget.

Environment

• OS: Linux
• Terminal Emulator: kitty
• Crate version: 0.19
• Backend: crossterm

Additional context