wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-27 07:18:13 +03:00
Code Issues Projects Releases Wiki Activity
e331ff3626
wezterm/wezterm-gui/Cargo.toml

88 lines
2.3 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"
# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[build-dependencies]
anyhow = "1.0"
[target.'cfg(windows)'.build-dependencies]
embed-resource = "1.3"
cc = "1.0"
[dependencies]
anyhow = "1.0"
bitflags = "1.0"
codec = { path = "../codec" }
config = { path = "../config" }
downcast-rs = "1.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"
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
filedescriptor = { version="0.7", path = "../filedescriptor" }
hdrhistogram = "7.1"
build(deps): bump http_req from 0.6.1 to 0.7.1 Bumps [http_req](https://github.com/jayjamesjay/http_req) from 0.6.1 to 0.7.1. - [Release notes](https://github.com/jayjamesjay/http_req/releases) - [Commits](https://github.com/jayjamesjay/http_req/compare/v0.6.1...v0.7.1) Signed-off-by: dependabot[bot] <support@github.com>
2020-12-10 10:11:17 +03:00
http_req = {version="0.7", default-features=false, features=["rust-tls"]}
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"
Update lru -> 0.6
2020-12-10 01:04:56 +03:00
lru = "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
luahelper = { path = "../luahelper" }
deps: update metrics from 0.12 -> 0.14
2021-02-04 10:50:29 +03:00
metrics = { version="0.14", features=["std"]}
deps: update to mlua 0.5
2021-01-13 21:06:35 +03:00
mlua = "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
mux = { path = "../mux" }
open = "1.4"
openssl = "0.10"
deps: update to ordered-float 2.1
2021-02-08 09:54:02 +03:00
ordered-float = "2.1"
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"
portable-pty = { path = "../pty", features = ["serde_support", "ssh"]}
promise = { path = "../promise" }
pulldown-cmark = "0.8"
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" }
textwrap -> 0.13
2020-12-10 01:07:35 +03:00
textwrap = "0.13"
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"
umask = { path = "../umask" }
unicode-normalization = "0.1"
wezterm: improve shaping of emoji This is one of those massive time sinks that I almost regret... As part of recent changes to dust-off the allsorts shaper, I noticed that the harfbuzz shaper wasn't shaping as well as the allsorts one. This commit: * Adds emoji-test.txt, a text file you can `cat` to see how well the emoji are shaped and rendered. * Fixes (or at least, improves) the column width calculation for combining sequences such as "deaf man" which was previously calculated at 3 cells in width when it should have just been 2 cells wide, which resulted in a weird "prismatic" effect during rendering where the glyph would be rendered with an extra RHS portion of the glyph across 3 cells. * Improved/simplified the clustering logic used to compute fallbacks. Previously we could end up with some wonky/disjoint sequence of undefined glyphs which wouldn't be successfully resolved from a fallback font. We now make a better effort to consolidate runs of undefined glyphs for fallback. * For sequences such as "woman with veil: dark skin tone" that occupy a single cell, the shaper may return 3 clusters with 3 glyphs in the case that the font doesn't fully support this grapheme. At render time we'd just take the last glyph from that sequence and render it, resulting in eg: a female symbol in this particular case. It is generally a bit more useful to show the first glyph in the sequence (eg: person with veil) rather than the gender or skin tone, so the renderer now checks for this kind of overlapping sequence and renders only the first glyph from the sequence.
2020-11-24 00:45:38 +03:00
unicode-segmentation = "1.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
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" }
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: make opengl always required
2020-12-29 23:13:23 +03:00
window = { path = "../window", features=["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
[target."cfg(windows)".dependencies]
shared_library = "0.1"
winapi = { version = "0.3", features = [
"winuser",
"consoleapi",
"handleapi",
"fileapi",
"namedpipeapi",
"synchapi",
"winsock2",
]}
[features]
default = ["vendor_openssl"]
# FIXME: find a way to magically disable vendor_openssl only on linux!
vendor_openssl = ["openssl/vendored"]
Reference in New Issue Copy Permalink