Upcoming changes to the GUI mean that it will be double
the work to keep maintaining this, and it is already lagging
behind on pane support.
With the Mesa llvmpipe fallback we should be in a pretty
good state to not need another non-GL implementation.
I thought it would be cute to add an option to add a background image to
the window.
While playing around with the parameters, I accidentally implemented
window transparency on X11/Wayland, provided that you have a compositing
window manager. I don't know of the transparency also works on macOS or
Windows as of yet; will try that out once I push this commit.
This commit introduces three new configuration options explained below.
In the future I'd like to allow specifying equivalent settings in a
color scheme, and then that would allow setting per-pane background
images.
```lua
return {
--[[
Specifies the path to a background image attachment file.
The file can be any image format that the rust `image`
crate is able to identify and load.
A window background image is rendered into the background
of the window before any other content.
The image will be scaled to fit the window.
If the path is not absolute, then it will taken as being
relative to the directory containing wezterm.lua.
]]
window_background_image = "/some/file",
--[[ Specifies the alpha value to use when rendering the background
of the window. The background is taken either from the
window_background_image, or if there is none, the background
color of the cell in the current position.
The default is 1.0 which is 100% opaque. Setting it to a number
between 0.0 and 1.0 will allow for the screen behind the window
to "shine through" to varying degrees.
This only works on systems with a compositing window manager.
Setting opacity to a value other than 1.0 can impact render
performance.
]]
window_background_opacity = 1.0,
--[[
Specifies the alpha value to use when applying the default
background color in a cell. This is useful to apply a kind
of "tint" to the background image if either window_background_image
or window_background_opacity are in used.
It can be a number between 0.0 and 1.0.
The default is 0.0
Larger numbers increase the amount of the color scheme's
background color that is applied over the background image.
This can be useful to increase effective contrast for text
that is rendered over the top.
]]
window_background_tint = 0.0,
}
```
refs: https://github.com/wez/wezterm/issues/141
This is similar in spirit to the work in 4d71a7913a
but for Windows.
This commit adds ANGLE binaries built from
07ea804e62
to the repo. The build and packaging will copy those into the same
directory as wezterm.exe so that they can be resolved at runtime.
By default, `prefer_egl = true`, which will cause the window
crate to first try to load an EGL implementation. If that fails,
or if `prefer_egl = false`, then the window crate will perform
the usual WGL initialization.
The practical effect of this change is that Direct3D11 is used for the
underlying render, which avoids problematic OpenGL drivers and means
that the process can survive graphics drivers being updated.
It may also increase the chances that the GPU will really be used
in an RDP session rather than the pessimised use of the software
renderer.
The one downside that I've noticed is that the resize behavior feels a
little janky in comparison to WGL (frames can render with mismatched
surface/window sizes which makes the window contents feel like they're
zooming/rippling slightly as the window is live resized). I think this
is specific to the ANGLE D3D implementation as EGL on other platforms
feels more solid.
I'm a little on the fence about making this the default; I think
it makes sense to prefer something that won't quit unexpectedly
while a software update is in progress, so that's a strong plus
in favor of EGL as the default, but I'm not sure how much the
resize wobble is going to set people off.
If you prefer WGL and are fine with the risk of a drive update
killing wezterm, then you can set this in your config:
```lua
return {
prefer_egl = false,
}
```
refs: https://github.com/wez/wezterm/issues/265
closes: https://github.com/wez/wezterm/issues/156
This changes the ALT/dead key behavior a little bit more,
and in a way that is likely more useful to terminal users.
The default behavior is that system dead key processing is enabled.
For example, with DEU keyboard layout activated:
* `^` `<SPACE>` results in a single `^`
* `^` `e` result in those two characters combining into an e with a
diacritic.
If the config sets `use_dead_keys = false` then the behavior changes;
wezterm probes the active keymap to determine which keys are marked
as dead keys and computes their single character expansion. When
the dead key is pressed then that expansion is substituted instead.
So `^` is simply `^`.
In order to pull this off, the window layer needs to selectively
call `TranslateMessage` for the system dead key expansion case
instead of unconditionally in the global message loop.
As a result of *that*, it means that we don't perform the default ALT
key translation for every key press any more. I looked to see how old
friend putty handles this and found that it only allows default system
processing for ALT-space and ALT-F4. I was resistent to selectively
processing system shortcuts because the full set are effectively
unknowable to an application and I didn't want to try to replicate
a wide selection of varying keypresses. I'm fine to only allow
these two, so this commit does that, and reverts the portion of
the prior commit that prevented passing general ALT key combinations
through.
refs: #275
refs: #296
This commit teaches the config layer to distinguish between
explicitly configured fonts and automatic fallback fonts.
Font loading now maintains the set of loaded fonts. If after
loading from all configured sources a non-fallback font is
not present in the loaded set, wezterm will now pop up the
configuration error window to explain what is happening.
closes: #263
This will delay for the specified number of milliseconds.
This is an async function; it won't block the gui thread,
it will deschedule running the script and resume it once
the timeout has expired.
refs: #222
This commit adds very basic first passes at representing the Pane
and GuiWindow types in lua script.
The `open-uri` event from 9397f2a2db
has been redefined to receive `(window, pane, uri)` parameters
instead of its prior very basic `uri` parameter.
A new key assignment `wezterm.action{EmitEvent="event-name"}` is
now available that allows a key binding assignment to emit an arbitrary
event, which in turn allows for triggering an arbitrary lua callback
in response to a key or mouse click.
`EmitEvent` passes the `(window, pane)` from the triggering window and
pane as parameters.
Here's a brief example:
```lua
local wezterm = require 'wezterm';
wezterm.on("my-thingy", function(window, pane)
local dims = pane:get_dimensions();
wezterm.log_error("did my thingy with window " .. window:window_id() ..
" pane " .. pane:pane_id() .. " " .. dims.cols .. "x" .. dims.viewport_rows);
window:perform_action("IncreaseFontSize", pane);
end)
return {
keys = {
{key="E", mods="CTRL", action=wezterm.action{EmitEvent="my-thingy"}},
}
}
```
refs: #223
refs: #225
This builds on the new lua event handler plumbing added
in ccea650a93 to co-opt
the default URI opening action:
```lua
wezterm.on("open-uri", function(uri)
if uri:find("jira") then
wezterm.log_error("do something with jira")
wezterm.run_child_process({
"wezterm",
"start",
"--",
"jira",
"view",
extract_task_from_uri(uri)
})
-- prevent the default action from opening in a browser
return false
else
-- log but allow the uri to be opened in the browser
wezterm.log_error("clicken " .. uri)
end
end)
```
This doesn't allow exactly the sketched out option from
issue #223 to be implemented, but may be close enough
to be useful.
refs: #223
refs: #225
* `wezterm.on("event-name", func)`
* `wezterm.emit("event-name", "arg1", "arg2")`
`on` allows registering multiple functions.
`emit` will call each of the registered functions in turn, passing
a copy of the arguments. If a handler returns false, no additional
handlers are called and `emit` will return false. Otherwise,
once all the handlers have been called, `emit` will return true.
`emit` is capable of being called by async code.
These functions are available to the config layer, but nothing in
wezterm uses them at this time.
refs: #225
* Taught wezterm-mux-server how to `--daemonize` on windows
* Removed pty based command spawn used to spawn unix domain servers.
This was present because it was the only way to successfully spawn
wsl in the past. What I'm finding today is that it doesn't work
at all for me, generating an `0xc0000142` Application failed to
initialize error. A plain command builder spawn seems to work,
so that's what we're going with.
* Ensure that we put `.exe` on executable name on windows, otherwise
the spawn may fail.
* `Path::exists()` always returns false for unix domain sockets on
Windows, so unconditionally try to remove the socket before binding,
otherwise the bind will falsely fail, claiming that another process
is already bound.
The docs for mux will need to be updated to show how to revise them
for the new mux server invocation:
```lua
unix_domains = {
{
name = "wsl",
serve_command = {"wsl", "wezterm-mux-server", "--daemonize"}
},
}
```
kindof a lot going on in this commit, unintentionally:
* Need the lua context set to be moved into the config crate
otherwise configs cannot be parsed by the server and we end
up with the default configs
* Make the server use smol for async io
* Drop the use of the daemonize crate, which I had forked anyway.
Just inline our own tighter daemonize module
* Improve daemon spawning synchronization, however, it still needs
work for windows to avoid blocking forever where we don't do
daemonizing.
