Having time to spend I was toying with an idea the David Simmons offered in one of his blogs (https://cafbit.com/post/cursive_writing_terminal_applications_in_rust/). I took linear.rs and translated it into an mvc lookalike. Because I wanted to see keystrokes as well, I added 'q' and 'Q' to quit the example.

Let me know if you think it is worth showing, or not. Any way, all praise goes to David Simmons and all critics belong to me alone :-).

I renamed it mvc-linear to show the difference with linear.

A lot of changes have happened since 0.12, going to skip 0.13 and aim for the coming 0.14 in this PR. Which is going to have a very nice event reading system. People can use this branch if they want to be on the latest crossterm, however, the dependency branch is still a WIP, and changes can still happen and it might be broken sometimes. We do have settled on the public API. So I don't think anything is going to be changed about that.

• Implemented back/foreground color support
• Migrated 0.13 changes
• Migrated 0.14 changes
• Removed AsyncReader
• Reordered trait methods
• Implemented terminal reseize events
• Cleaned up some code
• Moved parsing logic into From trait implementations.

Ncurses is nice, but is pretty much terrible.

Intersting alternatives currently include rustty and termion.

First step would be to remove references to ncurses types from the public API (there's not a lot left).

I rewrote the test backend, I am starting slowly to write first tests ( https://github.com/njskalski/sly-editor/blob/master/src/file_dialog.rs ) figuring out what querying interface should look like. Any advice / constructive criticism appreciated.

First: Suggestion / Help

Problem description

Context: I've got a toy re-implementation of React in Rust generating a Virtual DOM. It's already handling layout via Stretch. I'm trying to use Cursive as one 'DOM' backend to show a new novel use case of implementation.

I'm trying to find the best method to absolute position the views according to my position/size information. Looks like it's not supported? Is my best bet to fork LinearLayout into an absolute view?

Environment

• Operating system: Windows
• Backend used: crossterm
• Current locale (run locale in a terminal). en_US.UTF-8
• Cursive version 15

When testing a change to an application using Cursive (the application is tupm of david simmons), I found the input that I put into the dialogs in my vi files (that were still open) between the rest of the code. As a terminal emulator I use terminator. I had two terminator windows open and the window1 contained two sub windows, each with one vi open on my code. Window2 was just one terminal window and was where I compiled and executed tupm.

After testing my change, which was entering a new account, canceling and then entering a new account and saving, I found that the exact data I had input in the dialog, was in both of my vi sessions right in between the code! Plus the status line revealed a weird status "I-C-X" and a remark pertaining to a search of some sort.

I have included screenprints here of both terminals. The code I was editing I will include in my github repo under gbonnema/tupm and branch separation.

I have not repeated it yet, but I will after this issue and I will report on the result of it. You see my input for the dialogs in the vi windows in the lines with "gort x x x x" and the next one "madeup me thatissecret myown I just want to add an entry to the database.". The weird(er) thing is that the left vi session has the character "Add" prepended while the right vi session has the characters "impl" prepended to the second line (madeup).

My question for now is: is this a cursive thing, a ncurses thing or a terminator thing? I suspect the code in tupm has nothing to do with it, but I will commit the change to the separation branch.

I hope you have some idea of what is going on here.

Kind regards, Guus Bonnema.

hello

i am on macos how to install that library to my system

$ brew install ncurses Updating Homebrew... ==> Auto-updated Homebrew! Updated 1 tap (homebrew/core). ==> Updated Formulae skinny

Warning: homebrew/dupes/ncurses-6.0_2 already installed

Hi everyone,

for my project in needed some kind of displaying hexdata so I created a hexview which is accessable via https://github.com/hellow554/cursive_hexview

Please, feel free to file any issues, pullrequests, doc changes, more cats pics, everything. I would really like to get some feedback, because it's my first published rust project.

One particular thing I noticed is, that I can't use with_id or *_height/width methods on the view. What is necessary to be able to use them @gyscos ?

Anyhow, you are welcome to use is, commend it, fork it, change it with any ideas you might have.

This PR is implementing crossterm for Cursive. It is still a work in progress and has to be tested more. Down below you will find a list of thing that has to be checked or tested.

• [X] Keyboard Input Handling
• [X] Coloring
• [x] Mouse input Handling
  • [X] Linux
  • [x] Windows (seems to not always capture mouse)
• [x] Performance (Windows is a bit laggy sometimes)
• [x] Cursor Hiding Windows.

What is crossterm?

Crossterm is similar to termion a terminal manipulation library, however, it supports all UNIX systems and Windows systems down to Windows 7.

Hi,

I ran into:

thread 'main' panicked at 'attempt to subtract with overflow', /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/views/list_view.rs:229
stack backtrace:
   1:     0x7fc581953f6c - std::sys::imp::backtrace::tracing::imp::write::hdc68b25dedcd1db8
   2:     0x7fc581952a7e - std::panicking::default_hook::{{closure}}::h5edd4f46e38f8310
   3:     0x7fc581952763 - std::panicking::default_hook::hda32855a02198554
   4:     0x7fc581952f0b - std::panicking::rust_panic_with_hook::hdd2e2d2d6c308562
   5:     0x7fc581952d54 - std::panicking::begin_panic::h48ad6352979e67f1
   6:     0x7fc581952cc9 - std::panicking::begin_panic_fmt::h2ded1b6830a36623
   7:     0x7fc581952c57 - rust_begin_unwind
   8:     0x7fc5819b1d6d - core::panicking::panic_fmt::h2aae0852c2562c9f
   9:     0x7fc5819b1ca4 - core::panicking::panic::h7f49eacfb0b4c1fc
  10:     0x55ec0df23aa8 - <cursive::views::list_view::ListView as cursive::view::View>::layout::h68ec5254d2a965f7
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/views/list_view.rs:229
  11:     0x55ec0de98ccc - cursive::view::view_wrapper::ViewWrapper::wrap_layout::h9e9d7de1055dca60
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:45
  12:     0x55ec0de9aa7f - cursive::view::view_wrapper::<impl cursive::view::View for T>::layout::h0437efaaaa52fd53
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:78
  13:     0x55ec0de98dac - cursive::view::view_wrapper::ViewWrapper::wrap_layout::hdeb15779bd802288
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:45
  14:     0x55ec0de9abff - cursive::view::view_wrapper::<impl cursive::view::View for T>::layout::had410b533505ca6d
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:78
  15:     0x55ec0df208ce - <cursive::views::linear_layout::LinearLayout as cursive::view::View>::layout::he430049eeb1c48a1
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/views/linear_layout.rs:201
  16:     0x55ec0de98bec - cursive::view::view_wrapper::ViewWrapper::wrap_layout::h5b2fd4995ac90378
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:45
  17:     0x55ec0de9acbf - cursive::view::view_wrapper::<impl cursive::view::View for T>::layout::hc245bd8e062c3d60
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:78
  18:     0x55ec0de64ad4 - <cursive::views::shadow_view::ShadowView<T> as cursive::view::view_wrapper::ViewWrapper>::wrap_layout::he941d882bcdabd4d
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/views/shadow_view.rs:58
  19:     0x55ec0de9ab9f - cursive::view::view_wrapper::<impl cursive::view::View for T>::layout::h7bb1fefbf58cdf4a
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/view/view_wrapper.rs:78
  20:     0x55ec0df29ed9 - <cursive::views::stack_view::StackView as cursive::view::View>::layout::h7de8e74d223fe846
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/views/stack_view.rs:154
  21:     0x55ec0df356ba - cursive::Cursive::layout::h593ae75221da9ba7
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/lib.rs:494
  22:     0x55ec0df35df5 - cursive::Cursive::step::hc789d40ea1a7d171
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/lib.rs:570
  23:     0x55ec0df35c8f - cursive::Cursive::run::ha463ea6606b82047
                        at /home/m/.cargo/registry/src/github.com-1ecc6299db9ec823/cursive-0.4.1/src/lib.rs:552
  24:     0x55ec0deae19f - rikki::frontend::curses::start::h0dcd081ef2d42d16
                        at /home/m/archive/code/rust/rikki/src/frontend/curses/mod.rs:38
  25:     0x55ec0deae761 - rikki::main::heea4d07080c68991
                        at /home/m/archive/code/rust/rikki/src/main.rs:84
  26:     0x7fc581961567 - __rust_maybe_catch_panic
  27:     0x7fc58195b667 - std::rt::lang_start::h667ad30118861e80
  28:     0x55ec0deb3a12 - main
  29:     0x7fc57fa2752f - __libc_start_main
  30:     0x55ec0de62759 - _start
                        at ../sysdeps/x86_64/start.S:120
  31:                0x0 - <unknown>

Anything I can do about it?

I was following the tutorial, part 2, and got the following: I use: $ rustc --version rustc 1.11.0 (9b21dcd6a 2016-08-15) $ gnome-terminal --version GNOME Terminal 3.18.3 $ echo $LANG en_US.UTF-8

Any ideas why I got these garbages?

Is your feature request related to a problem? Please describe. StackView lays out and draws all layers, even if they are not visible. If you have a Stack of a bunch of fullscreen layers, it doesn't make any sense to layout and draw any but the front layer. However, StackView always calls layout/draw on all layers. You need a custom view and some hacks (like checking if the printer is focused in draw) to avoid this.

Describe the solution you'd like StackView should be clever enough to not call layout/draw on layers that are not being shown.

Describe alternatives you've considered As above, custom views can hack around this.

Is your feature request related to a problem? Please describe. I have a few specific events that basically invalidate any selections/focus in my SelectViews. These are cumbersome to handle with the current available access to SelectView.

Describe the solution you'd like .clear_selection() that would get rid of any selections/focus made, meaning no selection is highlighted (even when focus has already been lost) and no selection is returned by .selection().

Describe alternatives you've considered Right now I resorted to .clear() and rebuilding the view, but that's a waste if I could just call a function to clear any selections/focus made in SelectViews.

Describe the bug I think ScrollView slows down exponentially based on the content inside, even if that content isn't visible, or is hidden.

To Reproduce I have this layout hierarchy right now (naming excluded):

> ResizedView
    > LinearLayout
        > PaddedView (header)
           > TextView
           > HideableView (hidden)
               > ScrollView
                   > DebugView
           > HideableView (hidden)
               > ScrollView
                   > LoggerView
        > ResizedView
          > AlignedView
             > ScrollView
                 > LinearLayout
                     > PaddedView
                        > TextView
** Repeating element **
                 > LinearLayout (one section containing a title and a list of (expandable) items)
                     > TextView (section header basically)
                     > HideableView (might be hidden)
                         > ScrollView
                             > ListView
                                 > TextView
** Repeating element **
    > PaddedView (footer)
        > TextView

Expected behavior Faster draws if only 40 lines of text are actually displayed, and approximately 1000 in all the visible views.

Environment

• Operating system used: Ubuntu 22.04
• Backend used: crossterm
• Current locale: en_GB.UTF-8
• Cursive version: 0.20.0 (crates.io)

Consider the following code:

use cursive::traits::{Nameable, Resizable, Scrollable};
use cursive::views::{EditView, LinearLayout, ScrollView, TextView};
use cursive::Cursive;

fn main() {
    let mut siv = cursive::default();
    siv.add_fullscreen_layer(
        LinearLayout::vertical()
            .child(
                LinearLayout::vertical()
                    .scrollable()
                    .with_name("chatbox")
                    .full_height(),
            )
            .child(
                EditView::new()
                    .on_submit(sendtext)
                    .with_name("input")
                    .full_width(),
            ),
    );
    siv.run();
}

fn sendtext(s: &mut Cursive, line: &str) {
    s.call_on_name("chatbox", |view: &mut ScrollView<LinearLayout>| {
        view.get_inner_mut().add_child(TextView::new(line));
        view.scroll_to_bottom()
    });
    s.call_on_name("input", |view: &mut EditView| view.set_content(""));
}

My expectation is that, once enough lines have been submitted to fill up "chatbox", submitting another line will lead to that new line being visible on the row immediately above "input" due to the call to view.scroll_to_bottom(). In actuality, once "chatbox" is full, like so:

entering another line ("Line 24") will result in that new line being below the current-displayed portion of the ScrollView:

If another line ("Line 25") after that is entered, Line 24 will become visible, but Line 25 will remain unshown:

And likewise after entering Line 26:

If "chatbox" is then manually scrolled to the bottom (producing the visual result I expected in the first place):

Entering another line will return it to the old behavior:

Unlike #651, scroll_to_bottom() is indeed doing something, as removing that line results in the ScrollView never scrolling down no matter how many new lines are added.

Environment

• Operating system used: macOS 11.6.8, using GNU screen 4.09.00 (TERM=screen-256color) inside Terminal.app (TERM=xterm-256color)
• Backend used: ncurses
• Current locale:

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"

• Cursive version: 0.20.0 from crates.io

Is your feature request related to a problem? Please describe. At this point in time, cursive does not detect when multiple views are given the same name. Puzzling debugging sessions may ensue as call_on_name calls reach the wrong target.

Describe the solution you'd like Cursive should detect this API usage error and handle it. Panicking would most likely be appropriate here.

Describe alternatives you've considered

• APIs that name views, such as Nameable::with_name, could return a type that can handle the possibility of error, such as an Option or Result.
• These APIs could automatically generate derived names e.g. "RequestedName#123" and return that when a requested name is already taken.
• Usage of user-defined names could be replaced by collision-free alternatives, such as 64-bit integers generated by a global atomic counter.

However, I think this is too much of an edge case to justify expending so much implementation care and/or API surface on it.

(UPDATE: The bug is due to https://github.com/crossterm-rs/crossterm/issues/500 and there is work in progress to fix it at https://github.com/crossterm-rs/crossterm/pull/711)

The bug seems to be unique to the crossterm-backend, so I'm reporting the bug here: https://github.com/crossterm-rs/crossterm/issues/725

The rest of this text is copy/paste from the link above.

Describe the bug

Terminal is unresponsive when using Crossterm and Cursive, when enabling Cursive feature crossterm-backend.

Specifically, Cursive launches the TUI, but it doesn't respond to key presses.

For comparison, the same app works fine with other Cursive backends, including ncurses, pancurses, termion.

To Reproduce

Minimal reproduction code.

File Cargo.toml includes:

[dependencies]
cursive = { version = "*", features = ["crossterm-backend"] }

File main.rs:

fn main() {
    let mut c = cursive::crossterm();
    c.run();
}

Run:

./target/debug/demo

Cursive shows a blank screen, as expected.

Press ctrl-c to exit, as expected.

Run:

echo "" | ./target/debug/demo

Cursive shows a blank screen, as expected.

Press ctrl-c to exit-- but it doesn't work. This is the bug. A real-world app with more kinds of inputs has all of the fail, such as for Checkbox, EditView, tec.

Expected behavior

Expected: Cursive responds to keys.

Actual: Cursive does not responds to keys.

I've confirmed this problem happens with other kinds of UI/UX, such as other keypresses, and also by using other Cursive functionality, such as a TextView, or EditView, or Button, etc.

OS

macOS Ventura 13.0 on a MacBook Pro with Apple M1 Max chip

Terminal/Console

macOS Terminal app i.e. the default macOS terminal application

Question

When the Crossterm documentation states "It supports all UNIX and Windows terminals down to Windows 7", does Crossterm currently support UNIX on macOS with Apple M1? I ask because I see some past posts that discuss Crossterm macOS M1 issues/incompatibilities/roadmaps.

If yes, then what's the next step please, to troubleshoot this bug?

If no, then could a maintainer edit to the README and documentation to note that Crossterm is currently not intending to be run on macOS with Apple M1?

Thank you for your consideration.