We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
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.
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.
This was honestly a PITA because of its complexity. The `clipboard`
crate (now dropped as a dep) didn't support wayland, so I looked at
the `smithay-clipboard` crate, which caused all of my input to become
laggy just by enabling it--even without actually copying or pasting!
Both of those crates try to hide a number of details of working with
the clipboard from the embedding application, but that works against
our window crate implementation, so I decided to integrate it into
the window crate using Futures so that the underlying IPC timing and
potential for the peer to flake out are not completely hidden.
This first commit removes the SystemClipboard type from wezterm
and instead bridges the window crate clipboard to the term crate
Clipboard concept.
The clipboard must be associated with a window in order to function
at all on Wayland, to we place the get/set operations in WindowOps.
This commit effectively breaks the keyboard on the other window
environments; will fix those up in follow on commits.
It will pass the message text to the shell without proper quoting
which results in it running all sorts of garbage depending on
the message you're trying to display.
Very scary!
refs: https://github.com/jdm/tinyfiledialogs-rs/issues/19
We need to chunk the data that we read from the child otherwise
we may potentially try to admit more data in a single action
than the ratelimiter will ever allow (eg: if we read 4k of data
and the limit is 100 bytes per second, we can never send that
4k of data in a single write).
Our handling of that situation was not good: we'd panic and kill
the background thread that was reading the data, but the rest
of the app was still running.
This commit upgrades to the most recent rate limiter crate
and performs explicit chunking of the output so that we
behave more sanely.
Refs: https://github.com/wez/wezterm/issues/65
This is a little ghetto feeling because we're just stealing the top
line from the terminal model, rather than rendering anything
particularly native, but it is relatively quick and easy to do,
and helps improve the feel when using wezterm on a chromebook
inside crostini; in that environment, the system doesn't render
any text in the window titlebars (WTF!?) so it is desirable
to show something to help navigate the UI.
The tab bar is off by default for now; we'll definitely want to
add options to configure at least the colors, and perhaps add
a keybinding to toggle it at runtime.
```
enable_tab_bar = true
```
While adding support for the tab bar, I found a couple of little
bugs relating to computing the number of rows and columns; one
was during resize where we'd use the prior size instead of
the current size. Another was during tab spawning where we'd use
a slightly different calculation to determine the size and end
up raising an error about being confused about the screen size.
This is still a bit rough because the terminal parser doesn't
understand the pixel sizes, so it relies on the hard coded
cell dimensions being accurate.
This uses the same plumbing as the software frontend, but tries
to enable opengl.
None of the opengl rendering is plumbed through here yet, so this
is currently functionally identical to the software renderer.
Tested only on windows with a USB serial connector to my NUC running
linux.
This allows opening up wezterm on a serial port connection.
Serial is closer to a tty than a pty, so it is a bit different
to configure and use.
This commit allows running:
```
wezterm serial COM3
```
to open a window that connects to the specified COM port.
You can change the baud rate with:
```
wezterm serial --baud 9600 COM3
```
There are more options that could be set, but I'm a bit lazy and
have only exposed the baud rate to the wezterm cli so far.
In the early days we relied upon the bounded length of a sync channel
to put back pressure on the output from a child command. We're no
longer using that kind of channel, so here's a more deliberate and
measurable rate limiting implementation.
The `ratelimit_output_bytes_per_second` configuration setting defaults
to 2MB/s and constrains the amount of text we send to the escape
sequence parser.
This value was selected based on it being a combination of responsive
to ctrl-c while outputing a lot of data and still generating sleeps
to remain within the constraints.
This does mean that terminal benchmarks that test how quickly you
can dump text to the terminal will hit this artifical upper limit
and are thus not going to be a true measure of performance.
