wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-11-30 14:49:26 +03:00
Code Issues Projects Releases Wiki Activity
9559404c3c
wezterm/wezterm-gui/Cargo.toml

108 lines
2.8 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"]
add distro-defaults feature The intent is that when set, it changes defaults to something more suitable for distributions. I've also added a readme for distro maintainers. refs: https://github.com/wez/wezterm/issues/1795
2022-07-11 02:34:43 +03:00
distro-defaults = ["config/distro-defaults"]
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
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]
build(deps): bump embed-resource from 1.7.2 to 1.7.3 Bumps [embed-resource](https://github.com/nabijaczleweli/rust-embed-resource) from 1.7.2 to 1.7.3. - [Release notes](https://github.com/nabijaczleweli/rust-embed-resource/releases) - [Commits](https://github.com/nabijaczleweli/rust-embed-resource/compare/v1.7.2...v1.7.3) --- updated-dependencies: - dependency-name: embed-resource dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
2022-07-04 04:27:21 +03:00
embed-resource = "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
cc = "1.0"
[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"]}
deps: structopt -> clap 3
2022-05-28 17:07:52 +03:00
clap = {version="3.1", features=["derive"]}
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: update Main thing to note here is that the open crate has deprecated open::that_in_background, but made open::that non-blocking. I think this is OK, but I'm a little cagey about what will happen with this on Windows. We may need to spawn our own thread for this if things go awry.
2022-06-13 06:17:48 +03:00
colorgrad = "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
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" }
add wezterm.mux lua module The intent is to expose Mux related functions to lua, so `wezterm.mux` will be that module table. In order to test this out in the debug overlay, I realized that the overlay was running functions in a different thread and didn't have access to the mux, so this commit also tweaks the debug overlay repl to execute the input in the main thread. The result is that it is now possible to do `wezterm.mux.active_workspace()` in the debug overlay to print the active workspace name. More functions will follow. refs: https://github.com/wez/wezterm/issues/225
2022-06-17 17:46:25 +03:00
futures = "0.3"
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"
deps: image -> 0.24
2022-02-07 04:51:32 +03:00
image = "0.24"
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
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 wezterm.mux lua module The intent is to expose Mux related functions to lua, so `wezterm.mux` will be that module table. In order to test this out in the debug overlay, I realized that the overlay was running functions in a different thread and didn't have access to the mux, so this commit also tweaks the debug overlay repl to execute the input in the main thread. The result is that it is now possible to do `wezterm.mux.active_workspace()` in the debug overlay to print the active workspace name. More functions will follow. refs: https://github.com/wez/wezterm/issues/225
2022-06-17 17:46:25 +03:00
mlua = {version="0.8.0-beta.4", features=["send"]}
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" }
lua: add window:mux_window() and pane:mux_window() methods These allow converting the gui versions of these objects to the mux versions. refs: https://github.com/wez/wezterm/issues/225
2022-06-28 06:28:26 +03:00
mux-lua = { path = "../lua-api-crates/mux" }
deps: update Main thing to note here is that the open crate has deprecated open::that_in_background, but made open::that non-blocking. I think this is OK, but I'm a little cagey about what will happen with this on Windows. We may need to spawn our own thread for this if things go awry.
2022-06-13 06:17:48 +03:00
open = "3.0"
deps: ordered-float closes: https://github.com/wez/wezterm/pull/1946
2022-05-02 07:43:22 +03:00
ordered-float = "3.0"
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"
tabout = { path = "../tabout" }
terminfo = "0.7"
termwiz = { path = "../termwiz" }
config: split out lua functions into their own crates This shaves off some build time and allows more parallism in the build.
2022-05-19 08:49:53 +03:00
termwiz-funcs = { path = "../lua-api-crates/termwiz-funcs" }
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"
deps: tiny-skia -> 0.7 closes: #2219
2022-07-04 16:30:34 +03:00
tiny-skia = "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
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: add experimental_bidi config option and very basic bidi This commit is larger than it appears to due fanout from threading through bidi parameters. The main changes are: * When clustering cells, add an additional phase to resolve embedding levels and further sub-divide a cluster based on the resolved bidi runs; this is where we get the direction for a run and this needs to be passed through to the shaper. * When doing bidi, the forced cluster boundary hack that we use to de-ligature when cursoring through text needs to be disabled, otherwise the cursor appears to push/rotate the text in that cluster when moving through it! We'll need to find a different way to handle shading the cursor that eliminates the original cursor/ligature/black issue. * In the shaper, the logic for coalescing unresolved runs for font fallback assumed LTR and needed to be adjusted to cluster RTL. That meant also computing a little index of codepoint lengths. * Added `experimental_bidi` boolean option that defaults to false. When enabled, it activates the bidi processing phase in clustering with a strong hint that the paragraph is LTR. This implementation is incomplete and/or wrong for a number of cases: * The config option should probably allow specifying the paragraph direction hint to use by default. * https://terminal-wg.pages.freedesktop.org/bidi/recommendation/paragraphs.html recommends that bidi be applied to logical lines, not physical lines (or really: ranges within physical lines) that we're doing at the moment * The paragraph direction hint should be overridden by cell attributes and other escapes; see 85a6b178cfddee94b3ddb39c26652bbd5a973666 and probably others. However, as of this commit, if you `experimental_bidi=true` then ``` echo This is RTL -> عربي فارسی bidi ``` (that text was sourced from: https://github.com/microsoft/terminal/issues/538#issuecomment-677017322) then wezterm will display the text in the same order as the text renders in Chrome for that github comment. ``` ; ./target/debug/wezterm --config experimental_bidi=false ls-fonts --text "عربي فارسی ->" LeftToRight 0 ع \u{639} x_adv=8 glyph=300 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 2 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 4 ب \u{628} x_adv=4 glyph=244 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 6 ي \u{64a} x_adv=4 glyph=363 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 9 ف \u{641} x_adv=11 glyph=328 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 11 ا \u{627} x_adv=4 glyph=240 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 13 ر \u{631} x_adv=3.78125 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 15 س \u{633} x_adv=10 glyph=278 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 17 ی \u{6cc} x_adv=4 glyph=664 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 19 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 20 - \u{2d} x_adv=8 glyph=276 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 21 > \u{3e} x_adv=8 glyph=338 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs ``` ``` ; ./target/debug/wezterm --config experimental_bidi=true ls-fonts --text "عربي فارسی ->" RightToLeft 17 ی \u{6cc} x_adv=9 glyph=906 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 15 س \u{633} x_adv=10 glyph=277 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 13 ر \u{631} x_adv=4.78125 glyph=272 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 11 ا \u{627} x_adv=4 glyph=241 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 9 ف \u{641} x_adv=5 glyph=329 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 8 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 6 ي \u{64a} x_adv=9 glyph=904 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 4 ب \u{628} x_adv=4 glyph=243 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 2 ر \u{631} x_adv=5 glyph=273 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText 0 ع \u{639} x_adv=6 glyph=301 wezterm.font(".Geeza Pro Interface", {weight="Regular", stretch="Normal", italic=false}) /System/Library/Fonts/GeezaPro.ttc index=2 variation=0, CoreText LeftToRight 0 \u{20} x_adv=8 glyph=2 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 1 - \u{2d} x_adv=8 glyph=480 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs 2 > \u{3e} x_adv=8 glyph=470 wezterm.font("Operator Mono SSm Lig", {weight="DemiLight", stretch="Normal", italic=false}) /Users/wez/.fonts/OperatorMonoSSmLig-Medium.otf, FontDirs ; ``` refs: https://github.com/wez/wezterm/issues/784
2022-01-25 18:16:51 +03:00
wezterm-bidi = { path = "../bidi" }
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-client = { path = "../wezterm-client" }
config: cut over to wezterm-dynamic Avoid using serde for mapping between Lua and Rust for the `Config` struct. This improves the build speed of the config crate by 2x; it goes down from 30 seconds to 9 seconds on my 5950x.
2022-05-14 18:00:03 +03:00
wezterm-dynamic = { path = "../wezterm-dynamic" }
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-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" }
lua: add wezterm.window.screens() Currently implemented on X11 only, this function returns information about the geometry of the screen(s). This is taken from the same source of information we use for the `--position` CLI argument to `wezterm start`. ``` > wezterm.window.screens() { "by_name": { "DisplayPort-1": { "height": 2160, "name": "DisplayPort-1", "width": 3840, "x": 0, "y": 0, }, }, "main": { "height": 2160, "name": "DisplayPort-1", "width": 3840, "x": 0, "y": 0, }, "origin_x": 0, "origin_y": 0, "virtual_height": 2160, "virtual_width": 3840, } ```
2022-07-06 18:32:13 +03:00
window-funcs = { path = "../lua-api-crates/window-funcs" }
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"
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",
]}
Use newer windows crate
2022-03-07 03:01:59 +03:00
windows = { version="0.33.0", features = [
"Win32_UI_Shell",
]}
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
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"
deps: remove pretty_env_loggger Go directly to the underlying env_logger crate, as pretty_env_logger hasn't been updated in some time, and I'd like to be able to redirect the log output to a file more directly, and that feature is in a newer version of the env logger than pretty_env_logger was pulling in.
2022-04-07 18:22:46 +03:00
env_logger = "0.9"
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