-
-
Notifications
You must be signed in to change notification settings - Fork 352
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
Conversation
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. |
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 |
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 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 :-) |
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. |
fdehau said: Thanks @wez for the nice overview. This is a very impressive and ambitious project so if adding support in |
9ab4eb2
to
b6baea7
Compare
We should probably update |
Probably - I'll take a look at that sometime soon. |
Looks like we need to bump msrv to 1.60 for this.
|
Make that 1.63
|
8704393
to
732bf24
Compare
I don't thing the time thing is related to this PR directly - that dependency only comes via the It's specified as:
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. |
There was a problem hiding this 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!
A request for 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. |
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
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. |
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:
|
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 ```
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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