wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-11-24 07:46:59 +03:00
Code Issues Projects Releases Wiki Activity
7cc91696e9
wezterm/wezterm-client/Cargo.toml

49 lines
1.5 KiB
TOML
Raw Normal View History

split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
[package]
name = "wezterm-client"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[dependencies]
anyhow = "1.0"
async-trait = "0.1"
async_ossl = { path = "../async_ossl" }
codec = { path = "../codec" }
config = { path = "../config" }
filedescriptor: remove anyhow from public interface Use thiserror instead
2021-05-24 00:24:01 +03:00
filedescriptor = { version="0.8", path = "../filedescriptor" }
wezterm-client: sort dep list no functional change
2021-03-28 07:13:50 +03:00
futures = "0.3"
multiplexer: improve handling of image attachments There were a a couple of issues: * `ImageData::hash` would re-hash the image on every call, and this was called for every cell that comprised an image on the mux server side * `SerializedLine` needed to understand how to remove the `Arc<ImageData>` image attachments so that we didn't serialize a complete copy of the image per cell that comprised the image. A new RPC was introduced to attempt to fetch `ImageData` given its content hash and pane, row and cell index as a hint to locate it. A client side LRU of content hash to `ImageData` is used to avoid issuing repeat calls to that new RPC. refs: #1237
2022-03-29 06:21:37 +03:00
lazy_static = "1.4"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
log = "0.4"
thread original umask through when spawning mux server refs: #1633
2022-02-11 20:00:09 +03:00
libc = "0.2"
deps: lru 0.6 -> 0.7
2021-10-11 05:29:42 +03:00
lru = "0.7"
deps: cargo update, and a couple of dependabot suggestions
2021-07-19 05:10:46 +03:00
metrics = { version="0.17", features=["std"]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
mux = { path = "../mux" }
cargo update note: this pins the openssl crate to workaround the combination of these two issues: refs: https://github.com/sfackler/rust-openssl/issues/1630 refs: https://github.com/sfackler/rust-openssl/pull/1578
2022-05-09 06:50:47 +03:00
# Constrained to the last version of openssl that builds together with
# `openssl-sys = "=0.9.71"` which we are constrained to in libssh-rs
# until it switches back to openssl 3.x.
# https://github.com/sfackler/rust-openssl/issues/1630
# https://github.com/sfackler/rust-openssl/pull/1578
# https://github.com/wez/libssh-rs/blob/main/libssh-rs-sys/Cargo.toml
openssl = "=0.10.38"
wezterm-client: cut over to new wezterm-ssh bits refs: https://github.com/wez/wezterm/issues/507
2021-03-28 17:11:14 +03:00
portable-pty = { path = "../pty", features = ["serde_support"]}
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
promise = { path = "../promise" }
rangeset = { path = "../rangeset" }
ratelim= { path = "../ratelim" }
smol = "1.2"
wezterm-client: sort dep list no functional change
2021-03-28 07:13:50 +03:00
termwiz = { path = "../termwiz" }
deps: textwrap -> 0.15
2022-02-28 16:59:10 +03:00
textwrap = "0.15"
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
thiserror = "1.0"
thread original umask through when spawning mux server refs: #1633
2022-02-11 20:00:09 +03:00
umask = { path = "../umask" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
url = "2"
add Pane::get_metadata The idea here is that different kinds of panes may want to expose additional metadata to lua scripts. It would be a bit weird to add a Pane method for each of those and plumb it all the way through the various APIs, so just allowing a pane impl to return a dynamic value (likely an Object) allows a bunch of flexibility. This commit exposes the clientpane is_tardy boolean and the time since the last data was recevied (since_last_response_ms) from the mux client pane implementation: these are used to show the tardiness indicator in the client pane. Exposing this data enables the user to add that info to their status bar if they wish.
2022-09-02 07:27:49 +03:00
wezterm-dynamic = { path = "../wezterm-dynamic" }
wezterm-client: cut over to new wezterm-ssh bits refs: https://github.com/wez/wezterm/issues/507
2021-03-28 17:11:14 +03:00
wezterm-ssh = { path = "../wezterm-ssh" }
split gui into wezterm-gui executable This commit moves a bunch of stuff around such that `wezterm` is now a lighter-weight executable that knows how to spawn the gui, talk to the mux or emit some escape sequences for imgcat. The gui portion has been moved into `wezterm-gui`, a separate executable that doesn't know about the CLI or imgcat functionality. Importantly, `wezterm.exe` is no longer a window subsystem executable on windows, which makes interactions such as `wezterm -h` feel more natural when spawned from `cmd`, and should allow `type foo.png | wezterm imgcat` to work as expected. That said, I've only tested this on linux so far, and there's a good chance that something mac or windows specific is broken by this change and will need fixing up. refs: #301
2020-10-25 02:40:15 +03:00
wezterm-term = { path = "../term", features=["use_serde"] }
wezterm: fixup win32 build for wezterm-gui changes refs: #301
2020-10-25 03:00:07 +03:00
[target."cfg(windows)".dependencies]
deps: update
2021-12-20 18:15:56 +03:00
uds_windows = "1.0"
gui/client: add stubs for publishing a main gui instance sock path This will help to route things through a main gui instance per desktop session/class. Currently has stubs for windows.
2022-01-07 06:07:46 +03:00
winapi = { version = "0.3", features = [
"winuser",
]}
Reference in New Issue Copy Permalink