This meshes well with the sequence of instructions that we
get from harfbuzz.
This will need some vendoring to integrate with wezterm's build
on all platforms; that can come later.
Still need to hook up gradients.
We need to make a couple of passes over the paint instructions,
and making a nice interface around FontFuncs and DrawFuncs was
taking up a lot of boilerplate.
Adjust so that we accumulate parsed PaintOps and DrawOps instead.
This makes the code smaller and easier to grok.
Still has trouble rasterizing the new noto color emoji font though.
I'm experimenting with using cairo's 2D graphics for glyph related
drawing operations, and perhaps more stuff in the UI in the future.
The challenge is that no one has yet encapsulated its build in a
cargo-friendly way.
This commit is that attempt.
The strategy is this:
* `deps/cairo` is ostensibly the same thing as https://github.com/gtk-rs/gtk-rs-core/tree/master/cairo/sys
which is the cairo-sys-rs crate
* Its build.rs has been replaced with a version that builds from the C
sources that are found in-tree; it will never look for the system
cairo library
* A pair of scripts to import pixman (a required dep of cairo) and
cairo itself in a repeatable way are include, for if/when we need
to update the vendored sources
Cairo is a mature library and doesn't release very often.
* The workspace sets a patch for crates.io so that cairo-rs has
its cairo-sys-rs dep redirected to the local build.
I'm not planning to upstream this stuff to gtk-rs-core as full cairo
depends on a lot more things than are dealt with here, so it would be a
PITA to handle that generally.
This vendoring strips out things that are not used, so the cairo
library that remains:
* Is not internally thread safe; no TLS or mutex support is enabled
in either of them. That's fine because the high level cairo-rs
wrapper is not Send+Sync, which means that rust will only allow
it to be used single threaded anyway.
* Only has the basic recording and image surfaces
* No platform support for win32/xlib/xcb and so on
The vertical alignment is wonky, and some glyphs have the wrong
aspect and are missig colors. eg: the watermelon glyph in Noto Color
Emoji (U+1f349).
Turn this off by default, and skip loading fonts that have svg by
default.
Neither of these understand image protocols, and both are
an additional processing layer between the application and
wezterm.
This commit detects and wraps OSC sequences in tmux's passthru
sequence so that the data is passed on to wezterm rather than
elided from the data stream.
For image protocols in both tmux and conpty, work a little
smarter and explicitly move the cursor position to the same
location that wezterm would move it to. That prevents the
display from being as mangled by tmux/conpty due to a diverging
understanding of the cursor position.
The logic isn't perfect, and can result in the x-coordinate
being incorrect, and this won't work with the new --position
argument either in its current state, without adding a lot
of complexity to deal with scrolling and relative and absolute
positioning handling.
To facilitate that, a new termwiz Terminal trait method has
been added to probe the terminal name, version, cell and pixel
dimensions. It's not pretty.
refs: https://github.com/wez/wezterm/issues/3624
refs: https://github.com/wez/wezterm/issues/3716
Relocate the helper function to mux-server-impl and have both the GUI
and the mux server call it at the appropriate times.
Introduce default_mux_server_domain which is used instead of
default_domain in the mux server. This is to avoid recursive
cycles when starting up the mux; we don't want the default
domain to be a unix client that connects to our selves because
we'll try to connect to ourselves, then in act of handling that
spawn in the default domain and try to connect to ourselves and
repeat.
refs: https://github.com/wez/wezterm/issues/3907
* Change aliasing to exact matches of the color data.
* Don't "GC" away schemes that are no longer reachable from aggregators;
just because they are no longer listed elsewhere, doesn't mean that we
should remove the name/scheme from wezterm if it was already made
available in an earlier release.
refs: #3831
Error message I've been seeing the past couple of days:
Unable to resolve appearance using xdg-desktop-portal: invalid value:
string "()", expected at least one field signature between `(` and `)`:
invalid value: string "()", expected at least one field signature
between `(` and `)`
We need access to the underlying raw/physical key in order
to correctly encode in some modes, so we need the full KeyEvent
struct for that.
Move the encoder up so it sits alongside the win32 input mode
encoder.
This should give us better results for both shifted/unshifted
and the "base layout" (US english) representations of a number
of keys.
Note that this is still not 100% technically correct: the unshifted
keys require knowledge of the keyboard layout that we don't have
at this OS-independent layer.
Right now we're assuming a US layout to unshift punctuation, which
is not right if you're not using that layout. To resolve that,
more work is needed on each OS to be able to extract that information
and then to store it in the KeyEvent.
refs: https://github.com/wez/wezterm/issues/3479
refs: https://github.com/wez/wezterm/issues/2546
Previously, the config crate would get rebuilt each time the
git state changed, which has a lot of fan out and makes the build
take longer than it really needs to.
This commit breaks out the version changing stuff to its own crate
and then provides a runtime mechanism for assigning the version
information back into the config crate.
The env-bootstrap crate is responsible for setting that up.
