Open teohhanhui opened 4 years ago
Hey I'm really sorry; I just saw this issue.
I can't figure out what this means: "You should be able to just use crossterm and pass it a Terminal."
I was planning to get patches to crossterm
and the tui
crate merged that used this crate so that browser support is actually as seamless as the README alleges it is. Unfortunately I got sidetracked and never actually finished making the PRs.
This is more or less the API the README is describing.
And a more general question: I have an app which uses tui / crossterm. I'd like to be able to run it in the browser, in addition to Linux / macOS / Windows which are already supported. Do you have any suggestions on structure, so that all the xterm.js glue code is separated from the rest? Thanks!
This is what I was trying to do as well and actually why I made this crate!
The short answer is that: In general I think if you have your app only use the tui
API and use the crossterm
functions and macros (like write!
) only where needed (i.e. on startup to enable mouse capture, etc.) getting your app to run in a browser with xterm.js
should be pretty straightforward.
The longer answer is that you also have to be careful how you actually run your application (as in, how the thing that's usually called an event loop is set up) and how your app is structured; more on this below.
The examples in this repo don't aim to be runnable on desktop and the web, but they are all essentially unchanged from the examples they are based on with the exception of the main
methods (and a couple of other things related to compiling to wasm
and running in browsers).
I actually do have an example that does run on the web and on desktop here. That app is structured to have a library crate that both a desktop binary and a web binary crate depend on. The code is a little rough but I think comparing main
for the desktop app with run
for the web version and looking at the run_with_crossterm
and run_with_xtermjs
functions in the library crate should maybe provide some answers.
A couple of other odds and ends:
async
pervasively throughout the app; the lack of async trait methods is why we did not do this but I think the upsides (i.e. not having this kind of weird internal difference in how the app's event loop runs and actually being able to use async web APIs (i.e. most of them) in components) make it worth it
async-trait
make this not terribleweb-sys
) to do what you'd normally just use std
for will either be not a problem at all or will make supporting the web and desktops extremely difficult
#![no_std]
) so this wasn't a big deal for usWidget
trait (which is basically the tui
crate's StatefulWidget
trait — it didn't exist when we wrote ours)update
method on that trait async
I do still plan to get the patches to tui
(here) and crossterm
(here) merged in but I don't think that's going to happen in the near future.
It's possible to use this stuff right now, as the project I linked to does, but unfortunately I think if you try to use my forks of crossterm
and tui
like the UTP project does you'll run into problems with wasm-bindgen
(I had to fork that crate as well for some features xterm-js-sys
needed and got busy before I could get those changes upstreamed) since wasm-bindgen
intentionally does not follow semver and since they've had a few releases since I last updated my fork.
If you're interested in using this crate with crossterm
/tui
let me know and I can at least update my forks right away. And again, apologies for the very late response.
I can't figure out what this means: "You should be able to just use crossterm and pass it a Terminal."
And a more general question: I have an app which uses tui / crossterm. I'd like to be able to run it in the browser, in addition to Linux / macOS / Windows which are already supported. Do you have any suggestions on structure, so that all the xterm.js glue code is separated from the rest? Thanks!