Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(backend): add termwiz backend and example #5

Merged
merged 4 commits into from
May 12, 2023
Merged

feat(backend): add termwiz backend and example #5

merged 4 commits into from
May 12, 2023

Conversation

orhun
Copy link
Member

@orhun orhun commented Feb 12, 2023

Upstream: #300

Added termwiz backend which currently is tested in archlinux and works. It is using BufferedTerminal internally which should be doing diffs before applying the changes when calling flush.

As for windows it does compile but for some reason I don't see right chars being rendered.

//cc @wez

@orhun
Copy link
Member Author

orhun commented Feb 12, 2023

prabirshrestha said: @wez any idea why it doesn't render correctly in Windows? Once I quit alt screen also doesn't seem to go back clean. On linux it works as expected.

image

@orhun
Copy link
Member Author

orhun commented Feb 12, 2023

fdehau said: Thanks for the contribution. From a first read the code looks good. However, I'm a bit skeptical on the need for a new backend. Are there capabilities that are only provided by termwiz ? I was not aware that this crate existed until now, but my first impression is that it is a bit higher level than other backends and thus be seen as an other great take on a "framework" to build terminal applications. @wez what is your opinion on this ? I would be more than happy to list it as an alternative to tui as I've done for cursive.

@orhun
Copy link
Member Author

orhun commented Feb 12, 2023

wez said: @fdehau: My vision for termwiz is to enable cross platform (including first-class Windows support) text applications to detect and use a wide range of modern features in terminals, not only true color output (with a means to specify fallback on terminals that don't support it), but also including things like hyperlinks (OSC 8) and image protocols (currently iterm2 is supported, but I plan on adding sixel output soon).

termwiz has good low level foundations and optional nascent higher level support; it has an optional widget layer that is currently a bit lacking. termwiz shares the same core terminal model as wezterm, and my intent is that both will support a wide range of terminal attributes and display options.

I haven't looked at the internals in tui so I can't say whether you'd benefit from targeting the lower level API in termwiz or not, but I would suggest that it is worth evaluating that. The higher level stuff sounds like it may be a "competitor" to tui, but termwiz's widgets are pretty far behind in that "race" today :-)

@orhun
Copy link
Member Author

orhun commented Feb 12, 2023

prabirshrestha said: Currently wezterm widgets are very primitive so would like to use tui-rs instead. Given that I use wezterm as my terminal emulator I find it great that the same library can also be used for tui-rs which means any bug fixes or perf improvements that goes to wezterm comes for free by termwiz. termwiz does support different sent of features as mentioned earlier.

On windows there is currently only one backend so having a second backend would give more options to users.

Given that tui-rs doesn't have its own input handling apis I would like reuse the apis I'm already familiar with termwiz to build apps.

@orhun
Copy link
Member Author

orhun commented Feb 12, 2023

fdehau said: Thanks @wez for the nice overview. This is a very impressive and ambitious project so if adding support in tui can give it a bit more spotlight I would be more than happy to do so. Thanks also @prabirshrestha for detailing how you plan to use this new backend. Both of you made a good case :). As I said before, the code looks good so I'm wondering if @prabirshrestha want to investigate the Windows issues first or merge as is and iterate on the Windows support later ?

@mindoodoo mindoodoo added the Type: Enhancement New feature or request label Feb 14, 2023
joshka pushed a commit to joshka/ratatui that referenced this pull request Apr 28, 2023
@joshka joshka force-pushed the 300/termwiz branch 2 times, most recently from 9ab4eb2 to b6baea7 Compare May 3, 2023 05:27
@joshka
Copy link
Member

joshka commented May 3, 2023

Rebased on main, updated termwiz to 0.20, updated changes that had been made to termwiz lib since 0.9 (e.g. cell.style.fg -> cell.fg) and moved demo to the right place.

asciicast

@joshka joshka requested review from mindoodoo and sayanarijit May 3, 2023 05:28
@joshka joshka requested a review from sophacles May 3, 2023 06:20
@orhun
Copy link
Member Author

orhun commented May 3, 2023

We should probably update Makefile.toml to test it against this feature, right?

@joshka
Copy link
Member

joshka commented May 3, 2023

We should probably update Makefile.toml to test it against this feature, right?

Probably - I'll take a look at that sometime soon.

@joshka
Copy link
Member

joshka commented May 4, 2023

Looks like we need to bump msrv to 1.60 for this.

error: package `phf_shared v0.11.1` cannot be built because it requires rustc 1.60 or newer, while the currently active rustc version is 1.59.0
[cargo-make] ERROR - Error while executing command, exit code: 101
[cargo-make] WARN - Build Failed.
Error: Process completed with exit code 1.

@joshka
Copy link
Member

joshka commented May 4, 2023

Make that 1.63

error: package `time v0.3.20` cannot be built because it requires rustc 1.63.0 or newer, while the currently active rustc version is 1.60.0

@joshka joshka force-pushed the 300/termwiz branch 6 times, most recently from 8704393 to 732bf24 Compare May 4, 2023 11:49
@sophacles
Copy link
Contributor

I don't thing the time thing is related to this PR directly - that dependency only comes via the widget-calendar feature, and isn't used for wezterm stuff.

It's specified as:

time = { version = "0.3.11", optional = true, features = ["local-offset"]}

I'm not sure why 0.3.20 is getting pulled in for the builds. I'm not opposed to using the latest time crate (or at least latest compatable version) or bumping MSRV, but it might be some sort of smell that it's showing up in this unrelated PR.

Copy link
Contributor

@sophacles sophacles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice - thanks for the work on this!

@joshka
Copy link
Member

joshka commented May 5, 2023

It's specified as:

time = { version = "0.3.11", optional = true, features = ["local-offset"]}

I'm not sure why 0.3.20 is getting pulled in for the builds. I'm not opposed to using the latest time crate (or at least latest compatable version) or bumping MSRV, but it might be some sort of smell that it's showing up in this unrelated PR.

A request for 0.3.11 is a request for any 0.3.x where x > 11

I initially bumped MSRV to 1.60, which was necessary, but then got the other error for 1.63 due to time. Yeah, the 1.63 bump doesn't have to be part of this PR, but a MSRV bump does have to happen. My logic was that we may as well jump straight to 1.63 instead of the intermediate step.

@joshka joshka added the Type: Imported from tui-rs This issue / PR was Imported from tui-rs - kept for posterity / ease of finding historical ideas label May 5, 2023
@joshka joshka changed the title add termwiz backend and termwiz_demo feat(backend) add termwiz backend and example May 7, 2023
@joshka joshka changed the title feat(backend) add termwiz backend and example feat(backend): add termwiz backend and example May 7, 2023
@orhun
Copy link
Member Author

orhun commented May 9, 2023

So what exactly is the source of the MSRV change?

I see that it is related to calendar widget but what is the correlation between this PR?

@joshka
Copy link
Member

joshka commented May 9, 2023

So what exactly is the source of the MSRV change?

I see that it is related to calendar widget but what is the correlation between this PR?

When I rebased on main, the first thing that the ci picked up as failing on 1.59 was phf_shared (noted in #5 (comment), but the CI run has expired, so I can't point to the error).

Cargo tree for initial rebase
❯ cargo tree --all-features
ratatui v0.20.1 (/Users/joshka/local/ratatui)
├── bitflags v1.3.2
├── cassowary v0.3.0
├── crossterm v0.26.1
│   ├── bitflags v1.3.2
│   ├── libc v0.2.142
│   ├── mio v0.8.6
│   │   ├── libc v0.2.142
│   │   └── log v0.4.17
│   │       └── cfg-if v1.0.0
│   ├── parking_lot v0.12.1
│   │   ├── lock_api v0.4.9
│   │   │   └── scopeguard v1.1.0
│   │   │   [build-dependencies]
│   │   │   └── autocfg v1.1.0
│   │   └── parking_lot_core v0.9.7
│   │       ├── cfg-if v1.0.0
│   │       ├── libc v0.2.142
│   │       └── smallvec v1.10.0
│   ├── signal-hook v0.3.15
│   │   ├── libc v0.2.142
│   │   └── signal-hook-registry v1.4.1
│   │       └── libc v0.2.142
│   └── signal-hook-mio v0.2.3
│       ├── libc v0.2.142
│       ├── mio v0.8.6 (*)
│       └── signal-hook v0.3.15 (*)
├── serde v1.0.162
│   └── serde_derive v1.0.162 (proc-macro)
│       ├── proc-macro2 v1.0.56
│       │   └── unicode-ident v1.0.8
│       ├── quote v1.0.26
│       │   └── proc-macro2 v1.0.56 (*)
│       └── syn v2.0.15
│           ├── proc-macro2 v1.0.56 (*)
│           ├── quote v1.0.26 (*)
│           └── unicode-ident v1.0.8
├── termion v2.0.1
│   ├── libc v0.2.142
│   └── numtoa v0.1.0
├── termwiz v0.20.0
│   ├── anyhow v1.0.71
│   ├── base64 v0.21.0
│   ├── bitflags v1.3.2
│   ├── filedescriptor v0.8.2
│   │   ├── libc v0.2.142
│   │   └── thiserror v1.0.40
│   │       └── thiserror-impl v1.0.40 (proc-macro)
│   │           ├── proc-macro2 v1.0.56 (*)
│   │           ├── quote v1.0.26 (*)
│   │           └── syn v2.0.15 (*)
│   ├── finl_unicode v1.2.0
│   ├── fixedbitset v0.4.2
│   ├── hex v0.4.3
│   ├── lazy_static v1.4.0
│   ├── libc v0.2.142
│   ├── log v0.4.17 (*)
│   ├── memmem v0.1.1
│   ├── nix v0.24.3
│   │   ├── bitflags v1.3.2
│   │   ├── cfg-if v1.0.0
│   │   ├── libc v0.2.142
│   │   └── memoffset v0.6.5
│   │       [build-dependencies]
│   │       └── autocfg v1.1.0
│   ├── num-derive v0.3.3 (proc-macro)
│   │   ├── proc-macro2 v1.0.56 (*)
│   │   ├── quote v1.0.26 (*)
│   │   └── syn v1.0.109
│   │       ├── proc-macro2 v1.0.56 (*)
│   │       ├── quote v1.0.26 (*)
│   │       └── unicode-ident v1.0.8
│   ├── num-traits v0.2.15
│   │   [build-dependencies]
│   │   └── autocfg v1.1.0
│   ├── ordered-float v3.7.0
│   │   └── num-traits v0.2.15 (*)
│   ├── pest v2.6.0
│   │   ├── thiserror v1.0.40 (*)
│   │   └── ucd-trie v0.1.5
│   ├── pest_derive v2.6.0 (proc-macro)
│   │   ├── pest v2.6.0 (*)
│   │   └── pest_generator v2.6.0
│   │       ├── pest v2.6.0 (*)
│   │       ├── pest_meta v2.6.0
│   │       │   ├── once_cell v1.17.1
│   │       │   └── pest v2.6.0 (*)
│   │       │   [build-dependencies]
│   │       │   └── sha2 v0.10.6
│   │       │       ├── cfg-if v1.0.0
│   │       │       ├── cpufeatures v0.2.7
│   │       │       └── digest v0.10.6
│   │       │           ├── block-buffer v0.10.4
│   │       │           │   └── generic-array v0.14.7
│   │       │           │       └── typenum v1.16.0
│   │       │           │       [build-dependencies]
│   │       │           │       └── version_check v0.9.4
│   │       │           └── crypto-common v0.1.6
│   │       │               ├── generic-array v0.14.7 (*)
│   │       │               └── typenum v1.16.0
│   │       ├── proc-macro2 v1.0.56 (*)
│   │       ├── quote v1.0.26 (*)
│   │       └── syn v2.0.15 (*)
│   ├── phf v0.10.1
│   │   └── phf_shared v0.10.0
│   │       └── siphasher v0.3.10
│   ├── regex v1.8.1
│   │   ├── aho-corasick v1.0.1
│   │   │   └── memchr v2.5.0
│   │   ├── memchr v2.5.0
│   │   └── regex-syntax v0.7.1
│   ├── semver v0.11.0
│   │   └── semver-parser v0.10.2
│   │       └── pest v2.6.0 (*)
│   ├── sha2 v0.9.9
│   │   ├── block-buffer v0.9.0
│   │   │   └── generic-array v0.14.7
│   │   │       └── typenum v1.16.0
│   │   │       [build-dependencies]
│   │   │       └── version_check v0.9.4
│   │   ├── cfg-if v1.0.0
│   │   ├── cpufeatures v0.2.7
│   │   ├── digest v0.9.0
│   │   │   └── generic-array v0.14.7 (*)
│   │   └── opaque-debug v0.3.0
│   ├── signal-hook v0.1.17
│   │   ├── libc v0.2.142
│   │   └── signal-hook-registry v1.4.1 (*)
│   ├── siphasher v0.3.10
│   ├── terminfo v0.7.5
│   │   ├── dirs v4.0.0
│   │   │   └── dirs-sys v0.3.7
│   │   │       └── libc v0.2.142
│   │   ├── fnv v1.0.7
│   │   ├── nom v5.1.3
│   │   │   └── memchr v2.5.0
│   │   │   [build-dependencies]
│   │   │   └── version_check v0.9.4
│   │   └── phf v0.11.1
│   │       ├── phf_macros v0.11.1 (proc-macro)
│   │       │   ├── phf_generator v0.11.1
│   │       │   │   ├── phf_shared v0.11.1
│   │       │   │   │   └── siphasher v0.3.10
│   │       │   │   └── rand v0.8.5
│   │       │   │       └── rand_core v0.6.4
│   │       │   ├── phf_shared v0.11.1 (*)
│   │       │   ├── proc-macro2 v1.0.56 (*)
│   │       │   ├── quote v1.0.26 (*)
│   │       │   └── syn v1.0.109 (*)
│   │       └── phf_shared v0.11.1
│   │           └── siphasher v0.3.10
│   │   [build-dependencies]
│   │   └── phf_codegen v0.11.1
│   │       ├── phf_generator v0.11.1 (*)
│   │       └── phf_shared v0.11.1 (*)
│   ├── termios v0.3.3
│   │   └── libc v0.2.142
│   ├── thiserror v1.0.40 (*)
│   ├── ucd-trie v0.1.5
│   ├── unicode-segmentation v1.10.1
│   ├── vtparse v0.6.2
│   │   └── utf8parse v0.2.1
│   ├── wezterm-bidi v0.2.2
│   │   ├── log v0.4.17 (*)
│   │   └── wezterm-dynamic v0.1.0
│   │       ├── log v0.4.17 (*)
│   │       ├── ordered-float v3.7.0 (*)
│   │       ├── strsim v0.10.0
│   │       ├── thiserror v1.0.40 (*)
│   │       └── wezterm-dynamic-derive v0.1.0 (proc-macro)
│   │           ├── proc-macro2 v1.0.56 (*)
│   │           ├── quote v1.0.26 (*)
│   │           └── syn v1.0.109 (*)
│   ├── wezterm-color-types v0.2.0
│   │   ├── csscolorparser v0.6.2
│   │   │   ├── lab v0.11.0
│   │   │   └── phf v0.11.1 (*)
│   │   ├── deltae v0.3.1
│   │   ├── lazy_static v1.4.0
│   │   └── wezterm-dynamic v0.1.0 (*)
│   └── wezterm-dynamic v0.1.0 (*)
├── time v0.3.21
│   ├── libc v0.2.142
│   ├── num_threads v0.1.6
│   │   └── libc v0.2.142
│   └── time-core v0.1.1
├── unicode-segmentation v1.10.1
└── unicode-width v0.1.10
[dev-dependencies]
├── argh v0.1.10
│   ├── argh_derive v0.1.10 (proc-macro)
│   │   ├── argh_shared v0.1.10
│   │   ├── proc-macro2 v1.0.56 (*)
│   │   ├── quote v1.0.26 (*)
│   │   └── syn v1.0.109 (*)
│   └── argh_shared v0.1.10
├── indoc v2.0.1 (proc-macro)
└── rand v0.8.5
    ├── libc v0.2.142
    ├── rand_chacha v0.3.1
    │   ├── ppv-lite86 v0.2.17
    │   └── rand_core v0.6.4
    │       └── getrandom v0.2.9
    │           ├── cfg-if v1.0.0
    │           └── libc v0.2.142
    └── rand_core v0.6.4 (*)

I then bumped MSRV to 1.60 and hit the next MSRV requrement for time (1.63) in #5 (comment)

That MSRV bump is needed the time crate in the calendar feature.
So this PR is not strictly required to bump to 1.63, but it requires an MSRV bump, which I discovered during this PR.
I'll move the bump over to a separate PR as it's not related to this.

@joshka
Copy link
Member

joshka commented May 9, 2023

I rebased this on main, incorporated your fixups (spacing and vscode), and changed the MSRV bump back to 1.60.0.

The CI checks for this fails as it updates the time crate to the latest version which now requires rust 1.65.0:

 [cargo-make] INFO - Execute Command: "cargo" "test" "--no-default-features" "--features" "serde,crossterm,all-widgets" "--lib" "--tests" "--examples"
 Downloading crates ...
  Downloaded time-core v0.1.1
  Downloaded num_threads v0.1.6
  Downloaded time v0.3.21
error: package `time v0.3.21` cannot be built because it requires rustc 1.65.0 or newer, while the currently active rustc version is 1.60.0
[cargo-make] ERROR - Error while executing command, exit code: 101
[cargo-make] WARN - Build Failed.
Error: Process completed with exit code 1.

joshka and others added 3 commits May 9, 2023 13:58
The latest version of the time crate requires Rust 1.65.0

```
cargo +1.64.0-x86_64-apple-darwin test --no-default-features \
  --features serde,crossterm,all-widgets --lib --tests --examples
error: package `time v0.3.21` cannot be built because it requires rustc
1.65.0 or newer, while the currently active rustc version is 1.64.0
```
@joshka joshka self-requested a review May 9, 2023 21:19
@joshka
Copy link
Member

joshka commented May 9, 2023

In #171 I bumped the MSRV to 1.65.0. I've rebased this PR on top of that one, and removed the MSRV 1.60 commit. Assuming that PR is merged, I think this would be also ready to merge.

Copy link
Member

@joshka joshka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving as @orhun made the initial PR and although I fixed it up, this needs 2 approvals.
🤷‍♂️
Only merge this based on @orhun's actual approval though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Enhancement New feature or request Type: Imported from tui-rs This issue / PR was Imported from tui-rs - kept for posterity / ease of finding historical ideas
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

5 participants