Adjusts the background rendering logic so that we now allocate
a render layer for each defined background layer. This allows
their individual opacity value to multiple and blend together.
As part of this, I noticed that the big jpegs I was using could
take 400ms or more to load, so I added a basic cache to avoid
loading the same image multiple times around a config reload.
This adds some types that will enable richer background images.
* Can specify multiple layers
* Each layer can select from image files or gradient definitions
* Layers have additional properties to specify positioning, scaling,
tiling and whether they scroll with the viewport.
None of the additional properties are hooked up yet.
This commit allows for the SplitPane internal action to use the
pane id of an existing pane as the source of the pane to be added
in the new split target, rather than spawning a new command.
This can be used to move a pane from one tab to another, and is
analagous to tmux's `join-pane` command.
refs: https://github.com/wez/wezterm/discussions/2043
refs: https://github.com/wez/wezterm/issues/1253
This commit:
* Logs atom names in property change events (makes it easier to
understand user's logs)
* Sets flags in cases where property changes might imply that a
configure or focus event should have or should be sent
* Adjusts the "unsure about state" logic so that it doesn't just
trigger on the initial paint, but also on those flags being set
refs: https://github.com/wez/wezterm/issues/1992
Make the layer allocation more dynamic, which makes it
possible for the box model stuff to allocate a layer based
on the zindex for an element.
Adjust the box model code to cascade the base zindex via
the layer context so that the render stage can select
the correct layer.
This fixes up rendering tabs over the top of the right status
area.
My windows build didn't work this morning, complaining:
; cargo build
Updating crates.io index
error: failed to select a version for the requirement `libgit2-sys = "^0.13.4"`
candidate versions found which didn't match: 0.13.2+1.4.2, 0.13.1+1.4.2, 0.13.0+1.4.1, ...
location searched: crates.io index
required by package `git2 v0.14.4`
... which satisfies dependency `git2 = "^0.14"` (locked to 0.14.4) of package `config v0.1.0 (C:\Users\wez\wez-personal\wezterm\config)`
... which satisfies path dependency `config` (locked to 0.1.0) of package `codec v0.1.0 (C:\Users\wez\wez-personal\wezterm\codec)`
... which satisfies path dependency `codec` (locked to 0.1.0) of package `wezterm v0.1.0 (C:\Users\wez\wez-personal\wezterm\wezterm)`
The cargo update downgraded the dep, but looking at crates.io the
requested revs look ok. Something is fishy.
I upgraded rust and ran cargo update again to get back on the
same git rev, so now this commit captures the other things
that changed.
Wraps up the changes from the following diff and allows for the modal
layer (and box model) to use alpha for poly quads.
Change the default background color for pane select to be slightly
transparent.
Each layer has the same 3-pass draw that we use for the main terminal
display.
These layers allow for potentially compositing between the layers.
That is untested at the moment as the upper layers use the box model
stuff which hard-codes its work to the vb index 1 which doesn't
use regular alpha blending.
I think this might only be a thing on Windows.
This commit speculatively (I'm on a mac at the moment!) allows tracking
the left/right control/shift modifier flags and passing that through
to the win32 input mode logic.
refs: https://github.com/wez/wezterm/issues/2009
harfbuzz can return incomplete overlapping runs when it processes
text in unicode NFD. Add another check for the case where we've
accumulated the bytes in the range 0-12 and then harfbuzz returns
another range of 6-12. We coalesce the two together so that we can
pass the full unresolved sequence to the next fallback pass.
refs: https://github.com/wez/wezterm/issues/2032
This is still a bit of a WIP, but this commit:
* Introduces a new "Modal" concept to the GUI layer. The intent is
that modal intercepts key and mouse events while active, and renders
over the top of the rest of the normal display.
I think there might be a couple of cases where key events skirt
through this, but this is good enough as a first step.
Also, the render is forced into layer 1 which has some funny side
effects: if the modal choses to render transparent, it will poke
a hole in the window because all the rendering happens together:
there aren't distinct layer compositing passes.
* Add a new PaneSelect action that is implemented as a modal.
It uses quickselect style alphabet -> pane label generation and
renders the labels over ~the middle of each pane using an
enlarged version of the window frame font. Typing the label
will activate that pane. Escape will cancel the modal.
More styling and docs will follow in a later commit.
refs: #1975
