Built using:
```
./FontForge-2020-11-07-21ad4a1-x86_64.AppImage --script $PWD/font-patcher "$PWD/src/unpatched-fonts/NerdFontsSymbolsOnly/NerdFontsSymbolsOnly Template 1000 em.ttf" --powerline --use-single-width-glyphs -out /tmp/nerd-fonts-out --fontawesome --fontawesomeextension --fontlinux --octicons --codicons --powersymbols --powerline --powerlineextra --mdi --weathericons
```
which is everything *except* Pomicons at the time of writing, pending
clarifications of its distribution license
(https://github.com/ryanoasis/nerd-fonts/issues/266)
refs: https://github.com/wez/wezterm/issues/1521
The default we use on macOS looks decent. Roboto is a similar
looking font that we can use for the other platforms.
I may make it the same on all three once I've had a chance
to compare it on a mac.
This commit switches back to wezterm-icon.svg as the source of
the icon, but modifies it:
* Removed mac style title bar + window manipulation icons
* Increases the corner radius
* Adjusts the text position and size
This makes it somewhere between the original and one of the alternate
icons in 98b71cbfb6
I chose to modify the original source as it didn't have padding
baked into the svg file, and I didn't feel like wrestling with
the contributed svg in inkscape to remove it.
When we're not being run by bash or zsh then we can't use
bashisms to test that we're bash or zsh.
Just use good old posix test syntax instead.
refs: #447
The heart of this issue was that the resize callbacks have two
layers of state; one in the low level window and one in the application
level window.
On Windows, the system triggers the low level callback prior to
opengl being initialized. Since the application level depends on
the opengl state, there are some code paths where it NOPs and
returns early if opengl isn't yet initialized.
When the system-wide display scaling is set to say 200%, the application
layer can't know the effective DPI of the window it is creating because
it doesn't know which monitor will be used or what its DPI will be.
New windows are created at the default DPI of 96, and we rely on the
resize events to detect the actual DPI and adjust the scaling in
the window.
The early call of the resize callback meant that the low level and
application level size/dpi state was out of sync and the result was
that the window had half as many pixels as it should, but that the
terminal model was still sized as though it had the correct amount
(twice as many as visible). This resulted in the window being too
small for the viewport.
The resolution is simple: we now suppress emitting the resize processing
until opengl has been initialized.
The test scenario for this is:
* Set system scaling to 100%
* Launch wezterm
* Set system scaling to 200%
* Observe that wezterm scales to match
* Press CTRL-SHIFT-N to spawn a new window
* Observe that the new window size matches the other window (previously
this one would be half the size)
While I was looking at this, I noticed that the manifest didn't
match the DPI awareness that we have in the code, so update that.
refs: https://github.com/wez/wezterm/issues/427
Converts the svg font to a path so that rendering doesn't
require the full Operator Mono font locally.
Adjust the update script to add 10% padding around the icon
on macOS as @erf suggests that the increased padding looks
better/more consistent with other macOS apps.
I was playing around with inkscape and this simple icon is
the result.
Add a script to generate the various bitmap icons for all three
platforms. It is intended to run on a Linux host.
Bundle the *Last Resort High-Efficiency* font from
https://github.com/unicode-org/last-resort-font/
version 13.001 (Oct 22 2020).
This provides a more useful fallback glyph than we'd otherwise
produce if there is no matching glyph in any of the fonts.
Its license is OFL-1.1 which is compatible with the other
bundled fonts.
This commit provides a shell script that hooks into bash and zsh
to enable OSC 7 and semantic zones.
The packaging for Fedora and Debian deploys that script to
/etc/profile.d.
This avoids having a green (by default) border around the cursor.
The dynamic color escape sequences have been updated to also
change the border color when the cursor background color is changed.
I changed this to `wezterm-gui` thinking it would be a hair more
efficient, but it makes it difficult to access the cli side of
things from the appimage.
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 commit adjusts the window layer to have it try to load EGL
implementations on macOS. This is important as the system
provided OpenGL implementation is deprecated and I wanted to
have a path forward for when it is finally removed.
If EGL fails to initialize, we fall back to the CGL/OpenGL
implementation that we used previously.
I've included binaries built for 64-bit intel from the MetalANGLE
project; here's how I built them:
```
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git --depth 1
git clone https://github.com/kakashidinho/metalangle --depth 1
cd metalangle
PATH=$PWD/../depot_tools:$PATH python scripts/bootstrap.py
PATH=$PWD/../depot_tools:$PATH gclient sync
PATH=$PWD/../depot_tools:$PATH gn --args="is_debug=false angle_enable_metal=true angle_enable_vulkan=false angle_enable_gl=false angle_build_all=false" gen out/Release
PATH=$PWD/../depot_tools:$PATH autoninja -C out/Release
```
Those steps are a little too long to want to put them directly
into the wezterm CI.
It is important for metalangle to be >= 8230df39a5
in order for scaling to be handled correctly when dragging windows
between monitors.
refs: https://github.com/kakashidinho/metalangle/issues/34
This is a bit of a switch-up, see this comment for more background:
refs: https://github.com/wez/wezterm/issues/265#issuecomment-701882933
This commit:
* Adds a pre-compiled mesa3d opengl32.dll replacement
* The mesa dll is deployed to `<appdir>/mesa/opengl32.dll` which by
default is ignored.
* When the frontend is set to `Software` then the `mesa` directory
is added to the dll search path, causing the llvmpipe renderer
to be enabled.
* The old software renderer implementation is available using the
`OldSoftware` frontend name
I'm not a huge fan of the subdirectory for the opengl32.dll, but
I couldn't get it to work under a different dll name; the code
thought that everything was initialized, but the window just rendered
a white rectangle.
These serve two purposes:
* Provide a consistent default font for new installations,
that happens to show off ligature and color emoji support
out of the box.
* Provide a reasonable fallback in case the configuration is broken
Both fonts are distributed under the terms of the OFL 1.1.
refs: https://github.com/wez/wezterm/issues/263
