wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-11-28 01:06:37 +03:00
Code Issues Projects Releases Wiki Activity
1704af88ba
wezterm/wezterm-gui/Cargo.toml

102 lines
2.4 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-gui"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"
build = "build.rs"
Raise minimum Rust version to 1.51, de-vendor openssl on unix Rust 1.51 allows addressesing a long-standing TODO which was that we shouldn't need to build a vendored copy of openssl on most sensible unix systems. We do require a vendored copy on macOS and Windows, but due to the way that Cargo's feature resolver worked, it wasn't possible for this requirement to be respected. Rust 1.51 introduces `resolver="2"` which can deal with this feature resolution! https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2 The upshot of this is that building wezterm on real unix systems that are not macos will now link against the system libssl, resulting in both a shorter compile time and less headaches arising from having a slightly different openssl used by wezterm than the rest of the system. cc: @jsgf
2021-03-25 19:34:00 +03:00
resolver = "2"
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
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
Allow building without wayland support You can run `cargo build --release --no-default-features` to build without wayland support. This is useful for systems that do not have wayland (eg: the `slint` distro).
2021-06-27 03:05:22 +03:00
[features]
default = ["wayland"]
wayland = ["window/wayland"]
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
[build-dependencies]
anyhow = "1.0"
[target.'cfg(windows)'.build-dependencies]
embed-resource = "1.3"
cc = "1.0"
deps: windows 0.9 -> 0.11 closes: #872
2021-06-16 18:29:09 +03:00
windows = "0.11"
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
[dependencies]
anyhow = "1.0"
deps: update bitflags -> 1.3
2021-08-16 04:21:17 +03:00
bitflags = "1.3"
add debug overlay Adds a `ShowDebugOverlay` key assignment that will create a tab overlay that shows a limited number of recently logged events. refs: https://github.com/wez/wezterm/issues/641
2021-05-03 06:50:01 +03:00
chrono = {version="0.4", features=["unstable-locales"]}
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
codec = { path = "../codec" }
deps: colorgrad -> 0.5
2021-09-06 09:27:01 +03:00
colorgrad = "0.5"
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
config = { path = "../config" }
downcast-rs = "1.0"
term: allow iterm2 file transfer protocol Adds some plumbing to allow the GUI to implement a download handler and connect that up for iterm2 image/file transfers that have their inline property set to false. Previously we'd just log an error. Now we will by default download the file to the user's download directory. This behavior can be turned off via the new `allow_download_protocols` configuration setting. File transfers can be initiated on a remote host via the https://iterm2.com/utilities/it2dl script. When the download completes, a toast notification is shown that will open the file when clicked. refs: https://github.com/wez/wezterm/discussions/1450
2021-12-22 19:17:29 +03:00
dirs-next = "2.0"
wezterm: fixup APPIMAGE environment consistently Need to apply the same logic in wezterm-gui as we do in the wezterm-cli.
2020-10-25 09:21:03 +03:00
env-bootstrap = { path = "../env-bootstrap" }
deps: upgrade euclid -> 0.22
2020-12-10 21:03:16 +03:00
euclid = "0.22"
deps: update
2021-12-20 18:15:56 +03:00
fastrand = "1.6"
filedescriptor: remove anyhow from public interface Use thiserror instead
2021-05-24 00:24:01 +03:00
filedescriptor = { version="0.8", path = "../filedescriptor" }
launcher now has fuzzy matching Just start typing text to build up the fuzzy matching term. The list of items updates to match the results. refs: #664 refs: #1485
2022-01-04 18:45:15 +03:00
fuzzy-matcher = "0.3"
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
hdrhistogram = "7.1"
update http_req -> 0.8 0.8 doesn't seem to build with rusttls, but I don't think we need that any more: we've been using vendored openssl on windows and mac for some time. closes: #924 refs: https://github.com/jayjamesjay/http_req/issues/48
2021-07-07 23:37:57 +03:00
http_req = "0.8"
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
image = "0.23"
lazy_static = "1.4"
libc = "0.2"
log = "0.4"
deps: lru 0.6 -> 0.7
2021-10-11 05:29:42 +03:00
lru = "0.7"
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
luahelper = { path = "../luahelper" }
deps: cargo update, and a couple of dependabot suggestions
2021-07-19 05:10:46 +03:00
metrics = { version="0.17", features=["std"]}
Add get_foreground_process_name, expose it and cwd in PaneInformation Add `get_foreground_process_name` to both Pane and the lua wrapper. Add `foreground_process_name` and `current_working_dir` fields to `PaneInformation`. In order for those to be dynamically fetched, switch the lua conversion for `PaneInformation` to be a UserData with field access methods. It's a little more verbose but allows us to lazily compute these two new fields. refs: https://github.com/wez/wezterm/discussions/1421 refs: https://github.com/wez/wezterm/issues/915 refs: https://github.com/wez/wezterm/issues/876
2021-12-24 04:44:12 +03:00
mlua = "0.7"
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" }
deps: upgrade open 1.4 -> 2.0 The main difference is that it can now use `wslview` to open things across wsl boundaries. closes: #982
2021-07-26 18:15:02 +03:00
open = "2.0"
deps: ordered-float -> 2.10 closes: https://github.com/wez/wezterm/pull/1524
2022-01-10 05:25:48 +03:00
ordered-float = "2.10"
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
palette = "0.5"
Fix spawning new tabs/windows in directory with urlunsafe paths The CWD is internally stored as URL. The path component is therefore stored percent_encoded. It must be decoded before use.
2021-05-15 23:05:10 +03:00
percent-encoding = "2"
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
portable-pty = { path = "../pty", features = ["serde_support", "ssh"]}
promise = { path = "../promise" }
deps: update pulldown_cmark, cargo update
2021-12-27 19:49:22 +03:00
pulldown-cmark = "0.9"
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
rangeset = { path = "../rangeset" }
ratelim= { path = "../ratelim" }
regex = "1"
serde = {version="1.0", features = ["rc", "derive"]}
serde_json = "1.0"
serial = "0.4"
smol = "1.2"
structopt = "0.3"
tabout = { path = "../tabout" }
terminfo = "0.7"
termwiz = { path = "../termwiz" }
cargo update
2021-06-07 18:32:05 +03:00
textwrap = "0.14"
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"
deps: tiny-skia -> 0.6
2021-08-23 17:48:13 +03:00
tiny-skia = "0.6"
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
umask = { path = "../umask" }
unicode-normalization = "0.1"
deps: update unicode-segmentation to 1.8
2021-08-12 07:56:30 +03:00
unicode-segmentation = "1.8"
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
unicode-width = "0.1"
url = "2"
walkdir = "2"
wezterm-client = { path = "../wezterm-client" }
wezterm-font = { path = "../wezterm-font" }
wezterm-gui-subcommands = { path = "../wezterm-gui-subcommands" }
wezterm-gui: we now start an implicit unix mux server When running the GUI, we generate a unix domain socket path for the current process and start up a mux server for that path. This allows `wezterm cli list` and `wezterm cli split-pane` to work implicitly inside the GUI session. When started in this way, the mux server is not persistent; when the GUI process is terminated, all of its windows, tabs and panes are terminated. refs: https://github.com/wez/wezterm/issues/230
2020-12-30 02:58:39 +03:00
wezterm-mux-server-impl = { path = "../wezterm-mux-server-impl" }
RemoteSshDomain now uses wezterm-ssh crate There are a few notable changes as a result: * A number of `.ssh/config` options are now respected; host matching and aliasing and identity file are the main things * The authentication prompt is inline in the window, rather than popping up a separate authentication window Refs: https://github.com/wez/wezterm/issues/457
2021-03-28 03:49:30 +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"] }
tweak updating checking * Allow injecting some initial output to new panes * Have the update checker set this new-pane-banner to a short upsell to let the user know there is an update. * Refactor toast notifications into their own crate * Have the update checker call a new stub function that triggers a toast notification with an URL... but it does nothing because the rust ecosystem doesn't support this on macos yet and I'm writing this code there
2020-12-13 11:17:10 +03:00
wezterm-toast-notification = { path = "../wezterm-toast-notification" }
window: wayland support is no longer optional at build time
2021-05-09 01:20:23 +03:00
window = { path = "../window" }
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
[target."cfg(windows)".dependencies]
shared_library = "0.1"
deps: update
2021-12-20 18:15:56 +03:00
uds_windows = "1.0"
deps: windows 0.9 -> 0.11 closes: #872
2021-06-16 18:29:09 +03:00
windows = "0.11"
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
winapi = { version = "0.3", features = [
"winuser",
"consoleapi",
"handleapi",
"fileapi",
"namedpipeapi",
"synchapi",
"winsock2",
]}
Add shaper post-processing function This function is intended to deal with certain kinds of ligatures and certain combining sequences that don't have corresponding glyphs. It isn't hooked up to the gui yet, but does have unit tests that are probably mostly correct. refs: https://github.com/wez/wezterm/issues/478
2021-02-22 20:19:05 +03:00
[dev-dependencies]
update k9 to 0.11.0 to make it work with rustc@1.51.0 1.51.0 no longer takes non string literals in `panic()`. k9@0.11.0 fixes that
2021-03-25 20:32:31 +03:00
k9 = "0.11.0"
Add shaper post-processing function This function is intended to deal with certain kinds of ligatures and certain combining sequences that don't have corresponding glyphs. It isn't hooked up to the gui yet, but does have unit tests that are probably mostly correct. refs: https://github.com/wez/wezterm/issues/478
2021-02-22 20:19:05 +03:00
pretty_env_logger = "0.4"
benchmarking shaping `cargo test --release -p wezterm-gui -- --nocapture bench_shaping`: ``` running 1 test 100: 139.82µs 1000: 385.333µs 10000: 3.144203ms test shapecache::test::bench_shaping ... ok ```
2021-04-28 07:48:15 +03:00
benchmarking = "0.4"
Reference in New Issue Copy Permalink