wez/wezterm
1
1
Fork 0
mirror of https://github.com/wez/wezterm.git synced 2024-12-23 21:32:13 +03:00
Code Issues Projects Releases Wiki Activity
22b4e99c82
wezterm/window/Cargo.toml

74 lines
2.2 KiB
TOML
Raw Normal View History

add very basic win32 window creation
2019-08-08 05:19:04 +03:00
[package]
name = "window"
version = "0.1.0"
authors = ["Wez Furlong"]
edition = "2018"
repository = "https://github.com/wez/wezterm"
description = "Cross platform window setup and render"
license = "MIT"
window: take a stabe at EGL for linux/windows This doesn't initialize it at all properly yet, but is groundwork for completing that work in a later commit
2019-10-25 01:54:41 +03:00
build = "build.rs"
window: enable egl support for wayland
2019-11-30 05:05:09 +03:00
[dev-dependencies]
cargo update
2020-06-13 20:21:49 +03:00
pretty_env_logger = "0.4"
window: enable egl support for wayland
2019-11-30 05:05:09 +03:00
window: take a stabe at EGL for linux/windows This doesn't initialize it at all properly yet, but is groundwork for completing that work in a later commit
2019-10-25 01:54:41 +03:00
[build-dependencies]
window: glium and gl_generator version bump
2020-06-15 07:24:54 +03:00
gl_generator = {version="0.14", optional=true}
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
[dependencies]
window: adopt async_task for spawn_task
2020-01-16 12:31:28 +03:00
async-task = "1.2"
failure -> anyhow + thiserror
2019-12-15 08:43:05 +03:00
anyhow = "1.0"
thiserror = "1.0"
borrow input types from termwiz
2019-08-10 07:53:46 +03:00
bitflags = "1.0"
upgrade euclid dep
2019-09-21 22:32:21 +03:00
euclid = "0.20"
wezterm: improve texture atlas allocation This commit uses the guillotine algorithm to assign rectangles, which is superior to the dumb algorithm previously in use. In addition, in the first pass of painting, if we get a texture space error, we clear the atlas and try again without increasing it size, which should serve as the ultimate defrag. Subsequent passes will cause the texture to grow if needed. refs: #306
2020-10-23 23:57:58 +03:00
guillotiere = "0.6"
deps: normalize the lazy-static version
2020-11-13 18:57:09 +03:00
lazy_static = "1.4"
cargo update
2020-06-13 20:21:49 +03:00
libloading = { version = "0.6", optional=true }
add arbitrary line drawing with anti-aliasing
2019-08-11 20:15:08 +03:00
line_drawing = "0.8"
window: allow wayland and x11 to co-exist This is a pretty gross and coarse "smash them together" commit. There is some redundancy between the two connection and window impls that I'd like to unify later, but this lets us build with support for both systems for now.
2019-11-28 19:51:54 +03:00
log = "0.4"
instrument executor spawn delay
2020-01-04 19:52:50 +03:00
metrics = { version="0.12", features=["std"]}
bump some versions
2020-01-10 09:39:34 +03:00
palette = "0.5"
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
promise = { path = "../promise" }
resurrect bitmap render code from 236960e1a8e00dfcba6680de145daf1b494a6cf7 Earlier in the life of wezterm we had software rendering in src/xgfx.rs. This is the bitmap portion of that code from rev 236960e1a8e00dfcba6680de145daf1b494a6cf7, tweaked slightly for more recent changes to the palette crate.
2019-08-08 20:00:54 +03:00
resize = "0.3"
wezterm: add raw_code concept to input layer This commit is a bit noisy because it also meant flipping the key map code from using the termwiz input types to the window input types, which I thought I'd done some time ago, but clearly didn't. This commit allows defining key assignments in terms of the underlying operating system raw codes, if provided by the relevant layer in the window crate (currently, only X11/Wayland). The raw codes are inherently OS/Machine/Hardware dependent; they are the rawest value that we have available and there is no meaningful understanding that we can perform in code to understand what that key is. One useful property of the raw code is that, because it hasn't gone through any OS level keymapping processing, its value reflects its physical position on the keyboard, allowing you to map keys by position rather than by value. That's useful if you use software to implement eg: DVORAK or COLEMAK but want your muscle memory to kick in for some of your key bindings. New config option: `debug_key_events = true` will cause wezterm to log an "error" to stderr each time you press a key and show the details in the key event: ``` 2020-12-06T21:23:10.313Z ERROR wezterm_gui::gui::termwindow > key_event KeyEvent { key: Char('@'), modifiers: SHIFT | CTRL, raw_key: None, raw_modifiers: SHIFT | CTRL, raw_code: Some(11), repeat_count: 1, key_is_down: true } ``` This is useful if you want to figure out the `raw_code` for a key in your setup. In your config, you can use this information to setup new key bindings. The motivating example for me is that because `raw_key` (the unmodified equivalent of `key`) is `None`, the built-in `CTRL-SHIFT-1` key assignment doesn't function for me on Linux, but I can now "fix" this in my local configuration, taking care to make it linux specific: ```lua local wezterm = require 'wezterm'; local keys = {} if wezterm.target_triple == "x86_64-unknown-linux-gnu" then local tab_no = 0 -- raw codes 10 through 19 correspond to the number key 1-9 positions -- on my keyboard on my linux system. They may be different on -- your system! for i = 10, 20 do table.insert(keys, { key="raw:"..tostring(i), mods="CTRL|SHIFT", action=wezterm.action{ActivateTab=tab_no}, }) tab_no = tab_no + 1 end end return { keys = keys, } ``` Notice that the key assignment accepts encoding a raw key code using a value like `key="raw:11"` to indicate that you want a `raw_code` of `11` to match your key assignment. The `raw_modifiers` portion of the `KeyEvent` is used together with the `raw_code` when deciding the key assignment. cc: @bew
2020-12-07 00:23:37 +03:00
serde = {version="1.0", features = ["rc", "derive"]}
window: update to latest glium version
2020-10-12 03:07:47 +03:00
glium = { version = "0.28", optional=true, default-features = false}
extract window::input to wezterm-input-types
2020-12-10 00:00:23 +03:00
wezterm-input-types = { path = "../wezterm-input-types" }
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
[features]
window: take a stabe at EGL for linux/windows This doesn't initialize it at all properly yet, but is groundwork for completing that work in a later commit
2019-10-25 01:54:41 +03:00
opengl = ["cgl", "glium", "gl_generator", "libloading"]
upgrade to latest smithay client toolkit This version greatly improves the client side decoration handling under Wayland and allows rendering the window title in the titlebar (shocker!).
2020-05-03 01:53:32 +03:00
wayland = ["smithay-client-toolkit", "memmap", "wayland-client", "wayland-egl"]
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
[target."cfg(windows)".dependencies]
winapi = { version = "0.3", features = [
use dark mode
2019-08-08 08:10:30 +03:00
"dwmapi",
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
"handleapi",
Improve? IME on Windows This isn't perfect, but is sufficient to allow using the IME to enter eg: the heart emoji with cmd.exe. We have some issues locating and rendering chinese characters that make it difficult to prove/disprove that the IME is working 100% because we just can't see the glyphs. In addition, there appears to be something a bit wonky with conpty and emoji. If we use eg: `wezterm ssh HOST` to log in to a remote system, and use the IME to pick eg: the pig face emoji, this renders correctly. In that scenario we don't use conpty at all. The IME window is always placed in the top left corner of the window at the moment, which isn't great, but is better than the system default which is outside of the window. I need to introduce a way to set the IME position in the window layer so that the front end gui can set it to the current cursor position.
2019-11-02 19:35:19 +03:00
"imm",
window: tidy up crate deps
2019-08-08 19:13:22 +03:00
"libloaderapi",
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
"synchapi",
window: tidy up crate deps
2019-08-08 19:13:22 +03:00
"winerror",
"winuser",
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
]}
Respect wheel scrolling speed settings on Windows The default values are 3 lines. With this change, scrolling speed now seems similar to other programs like cmd.exe. Before this change it feels too slow.
2020-01-21 00:55:18 +03:00
winreg = "0.6"
window: fix build and clipboard on Windows
2019-11-29 23:32:30 +03:00
clipboard-win = "2.2"
Windows: fix enabling dark mode This got broken by a recentish windows update.
2020-10-18 05:48:43 +03:00
shared_library = "0.1"
add very basic win32 window creation
2019-08-08 05:19:04 +03:00
basic xcb windows too
2019-08-09 03:44:57 +03:00
[target.'cfg(all(unix, not(target_os = "macos")))'.dependencies]
point to local filedescriptor crate
2020-01-26 20:14:26 +03:00
filedescriptor = { version="0.7", path = "../filedescriptor" }
basic xcb windows too
2019-08-09 03:44:57 +03:00
x11 = {version ="2.18", features = ["xlib_xcb"]}
window: x11: fix minor leak of a display connection These were two separate one-time losses. refs: https://github.com/wez/wezterm/issues/238
2020-07-08 18:34:22 +03:00
xcb = {version="0.9", features=["shm", "xkb", "xlib_xcb"]}
upgrade to latest smithay client toolkit This version greatly improves the client side decoration handling under Wayland and allows rendering the window title in the titlebar (shocker!).
2020-05-03 01:53:32 +03:00
xcb-util = { features = [ "icccm", "ewmh", "keysyms", "shm"], version = "0.3" }
xkbcommon = { version = "0.5", features = ["x11", "wayland"], git="https://github.com/wez/xkbcommon-rs.git", rev="01a0a0cd5663405e6e4abb1ad3add9add1496f58"}
basic xcb windows too
2019-08-09 03:44:57 +03:00
mio = "0.6"
hook up paint method for x11
2019-08-09 21:15:09 +03:00
libc = "0.2"
window: update smithay-client-toolkit
2020-06-06 21:58:38 +03:00
smithay-client-toolkit = {version = "0.9", optional = true, features=["calloop"], git="https://github.com/wez/client-toolkit.git", branch="title_trunc"}
window: initial wayland render support
2019-11-28 03:39:00 +03:00
memmap = {version="0.7", optional=true}
upgrade to latest smithay client toolkit This version greatly improves the client side decoration handling under Wayland and allows rendering the window title in the titlebar (shocker!).
2020-05-03 01:53:32 +03:00
wayland-client = {version="0.26", optional=true}
wayland-egl = {version="0.26", optional=true}
really basic macos window
2019-08-09 06:53:16 +03:00
[target.'cfg(target_os="macos")'.dependencies]
remove local workaround for core-foundation UB issue My fixes landed upstream in https://github.com/servo/core-foundation-rs/commit/0a3ac83c1bb38d30a4d30530cd233385b7410b2c and are released already to crates.io
2019-11-13 11:05:55 +03:00
cocoa = "0.20"
really basic macos window
2019-08-09 06:53:16 +03:00
objc = "0.2"
window: fixup clipboard on macos
2019-11-29 23:47:56 +03:00
clipboard = "0.5"
remove local workaround for core-foundation UB issue My fixes landed upstream in https://github.com/servo/core-foundation-rs/commit/0a3ac83c1bb38d30a4d30530cd233385b7410b2c and are released already to crates.io
2019-11-13 11:05:55 +03:00
core-foundation = "0.7"
core-graphics = "0.19"
window: A basic opengl capability
2019-10-07 17:17:57 +03:00
cgl = { version = "0.3", optional = true }
Reference in New Issue Copy Permalink