I don't think font-kit has enough data available for to make things
work the way we're used to. In addition, the implementation of
the loader for core text has a lot of TODO's.
The state of the FontKit variant is that it basically renders glyphs
and they are aligned to the same baseline, but both the vert and
horz metrics are off; for example, `-` doesn't render. The glyphs
are also under-sized.
This is another option to help with the portable wezterm on a flash
drive use case.
When the font system is set to FontKitAndFreeType, the set of
directories specified by the `font_dirs` configuration option will
be scanned for fonts and used as a source for fonts.
In addition, any relative paths in the the `font_dirs` list will
be expanded relative to the configuration file path.
That allows deploying the following set of files to the root of
a flash drive:
* wezterm.exe
* wezterm.toml
* fonts/myfont.ttf
and with this config snippet:
```
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
```
wezterm will now consider myfont.ttf when loading fonts.
Refs: https://github.com/wez/wezterm/issues/73
This commit adds two new font system variants that are currently
implemented only on Windows:
* FontKit - uses fontkit both for font discovery and rasterizing
* FontKitAndFreeType - uses fontkit for font discovery but freetype
for rasterizing
To a certain extent, FontKitAndFreeType obsoletes FontLoaderAndFreeType
and I'll be looking at removing it once I can test the build on macOS.
The FontKit impl has bad metrics and also crashes during shaping
on Windows, so it's not ready to be used by default.
The NoticeXXX variants are emitted at the trigger point, but
we should wait for the debounced XXX variants instead. We
were doing this for write but not for delete. This should
improve the chances that we'll pick up a new version of a
config file.
Even with setting this, I'm 0 for 4 different systems in having the
notifications actually stay on the screen until dismissed.
This was successful at displaying a notification on the pixelbook
desktop though, so that's 1/3 linux systems that have had success.
The wayland changes rendered clipboard handling for remote multiplexers
broken, and this commit makes it work again.
It removes the clipboard concept from the the TerminalHost and
keeps it separated as the term::Clipboard concept.
The muxer now has plumbing for passing the Clipboard to its idea
of Windows and Tabs and this is hooked up at window creation and
domain attach time.
I noticed that we were relatively undersized for newly created
windows; there were two problems:
1. We weren't propagating the old rows and cols counts through
to the speculative resize.
2. The speculative resize wasn't implemented on wayland, and
needs a surprising amout of work to actually make the resize
take effect.
