rrbutani / xterm-js-sys

Rust bindings for Xterm.js
https://rrbutani.github.io/xterm-js-sys/examples
MIT License
33 stars 2 forks source link

[Question] How to use as a crossterm backend? #6

Open teohhanhui opened 4 years ago

teohhanhui commented 4 years ago

This crate has two features:

  • ...
  • crossterm-support: Provides a wrapper type that let's crossterm use xterm.js as a backend (located here). This enables xterm.js to be used with, for example,the tui crate. Usually you won't have to enable this feature yourself; you should be able to just use crossterm and pass it a [Terminal].

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!

rrbutani commented 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:

rrbutani commented 4 years ago

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.