@kalgynirae showed me weirdly laggy behavior when moving the mouse
in front of his x11 window. My suspicion was that this is somehow
related to updating the mouse cursor glyph, and looking at this code
there were two things that might influence this:
* We weren't saving the newly applied cursor value, so we'd create
a new cursor every time the mouse moved (doh!)
* We'd create a new cursor id each time it changed, and then destroy it
(which isn't that bad, but if it contributes to lag, maybe it is?)
This commit addresses both of these by making a little cache map
from cursor type to cursor id.
I can't observe a difference on my system, so I wonder if this might
also be partially related to graphics drivers and hardware/software
cursors?
Implement FromStr and Display for SshParameters, so that they can be
parsed and displayed in the standard way.
The motivation for this is that I want to add gateway hosts to the ssh command, and
would like to be able to add something like `gateway: Vec<SshParamters>` to SshCommand
to do it.
This allows child processes to "do something" with that information.
For example, portable wezterm deployments can use these paths to
bootstrap some other portable config paths.
refs: https://github.com/wez/wezterm/issues/152
The other default available macos monospace fonts have ligatures for
"fi" that are configured such that harfbuzz will render them when they
are part of a word like "finish" which results in a very weird
appearance.
Hiding a window is implemented as miniaturizing the window, which
is typically shown with an animation of the window moving into the
dock.
This is not the same as the application-wide hide function in macOS;
that function hides the entire app with no animation. We don't use
that here because our Hide function is defined as a window operation
and not an application operation.
refs: https://github.com/wez/wezterm/issues/150
derive_builder has some extra dependencies that take a while to compile.
The builder feature can be expressed via a 30-line macro. So let's do
that to make termwiz compile faster.
The palette crate has a codegen step that translates svg_colors.txt to named.rs.
That makes it hard to build using buck.
Remove the palette dependency so termwiz is easier to build using buck.
I made sure the following code:
fn main() {
use termwiz::color::RgbColor;
let r = RgbColor::from_rgb_str("#02abcd").unwrap();
let r1 = r.to_tuple_rgba();
let r2 = r.to_linear_tuple_rgba();
println!("r1 = {:?}", r1);
println!("r2 = {:?}", r2);
}
prints
r1 = (0.007843138, 0.67058825, 0.8039216, 1.0)
r2 = (0.000607054, 0.4072403, 0.6104956, 1.0)
before and after the change.
Change build.rs codegen to const_fns. This makes vtparse more friendly for buck
build.
Note const_fn functions still have limitation on the current stable (1.41)
rustc (ex. native "match" or "if" cannot be used in const_fn). So I used some
tricks to get it compile.
This helps to restore any individually dropped tabs and to detect
tabs that were created by other clients across a reconnection.
refs: https://github.com/wez/wezterm/issues/127
This is useful for setting up a reasonable initial environment.
For example, on Windows you might want to set the `prompt` environment
so that some basic shell integration is enabled; this will cause new
tabs to open with the same cwd as the current tab:
```
set_environment_variables = { "prompt"="$E]7;file://localhost/$P$E\\$P$G" }
```
This setting is intended to apply only to the local domain.
refs: https://github.com/wez/wezterm/issues/146
This allows this prompt setting to work:
```
prompt $E]7;file://localhost/$P$E\$P$G
```
although this one sets it for future prompts:
```
setx prompt $E]7;file://localhost/$P$E\$P$G
```
refs: https://github.com/wez/wezterm/issues/146
Embed rgb.txt and parse it on the fly to produce the list of colors.
This list is a superset of palette's SVG color list.
refs: https://github.com/wez/wezterm/pull/144
This is conceptually slightly cleaner and allows sessionhandler to
be agnostic of the details of the channel used to communicate with
the client; it just has a Sender<DecodedPdu> to work with.
