@jsgf mentioned this to me, and since I've started running "proper"
wayland gnome-shell/mutter on my pixelbook go, I'm seeing it too.
The issue is that the alpha values are potentially <1.0 when they
are committed to the frame buffer and the mutter compositor is
faithfully blending wezterm with the window behind it, leading to
weird looking effects such as varying brightness of text, or for
cases where the window behind wezterm is bright white, a halo
effect that makes the text less sharp.
This commit addresses this issue by asking glium to ask opengl to
set the destination alpha to 1.0 in the final draw stage.
I noticed this for small enough sizes of Fira Code the border width
for the cursor would round to zero, and then looking at eg: `man ls`,
the underlined portions had no underline.
Ensure that the underline size is at least 1 pixel.
On a Fedora 31 system running Wayland I noticed that wezterm and
the compositor were running pretty hot on their respective CPU
cores.
It turned out that we had a lot of
[Refresh](https://docs.rs/smithay-client-toolkit/0.6.4/smithay_client_toolkit/window/enum.Event.html#variant.Refresh)
events being generated and consumed. We were treating this as needing
a full paint so we'd be effectively continually running the opengl
paint cycle over and over.
The docs for that event say that it is intended to refresh the client
decorations so let's focus it towards that instead. This does bring
the CPU usage back down to intended levels.
I believe this hot CPU usage to be compositor-dependent: this is the
first I've seen of it out of 4 different Wayland environments!
* harfbuzz includes some ttf fixtures.
* libpng has some test images
* the wezterm web page has some movie files(!)
None of these are required to be in the source tarball, so strip them
out to save ~40MB and bring the tarball down to <5MB.
Refs: https://github.com/wez/wezterm/issues/46
The offset math around the scroll thumb made me uncomfortable
so this commit introduces a struct to keep track of the vertex
indices and make it easier to recall them later.
@fanzeyi ran into part of this issue when using multiplexing;
tabs from a remote domain always used the default color scheme
rather than the local configuration file color scheme.
Another variation on this is that making changes to the `[colors]`
section of the config only impacts tabs created after the change
was loaded, rather than updating the running tabs.
The root of this was that each terminal was keeping its own
copy of the palette that was updated at creation time to reflect
the config file. Relatively recently I introduced a new trait
to allow the terminal state to reach out and obtain configuration
from another source.
This commit connects the terminal configuration layer to the
configuration file directly.
The color schemes are now pulled directly from the configuration
file, except in the case where a dynamic color scheme has been
applied: using escape sequences to change the colors causes
the palette to be forked away from the configuration file.
There's still a low pri TODO around this space: if we're connected
to a remote domain and someone uses dynamic color scheme escapes,
should we reflect those locally? If so then we'll need to build
some plumbing to transport the palette to/from the remote system.
Closes: https://github.com/wez/wezterm/pull/60
This commit:
* Removes the ability to drag the window by the tab bar. I added
that in anticipation of needing to do custom title bar dragging
with Wayland, but it turned out both to be not required and not
possible to drag windows around in that way.
* Replaces the drag logic with dragging the scrollbar thumb
* Clicking above the scrollbar thumb is equivalent to page up
* Clicking below the scrollbar thumb is equivalent to page down
This commit adds a scrollbar that shows the scroll position but
that does not currently allow dragging to scroll.
The scrollbar occupies the right hand side window padding.
The width of the scrollbar can be set by explicitly configuring
`window_padding.right`. If the right padding is set to 0 (which
is its default value), and the scroll bar is enabled then the cell
width will be used for the right padding value instead.
The scrollbar can be enabled/disabled via this config setting:
```
enable_scroll_bar = true
```
Its color by this:
```
[colors]
scrollbar_thumb = "#444444"
```
(Note that color palette config will be reloaded when the config
file is changed, but you'll need to spawn a new tab/window to
see the effects because we cannot assume that a config reload should
always replace a potentially dynamically adjusted color scheme in
a tab).
This commit adds some plumbing for describing the cursor shape
(block, line, blinking etc) and visibility, and feeds that through
the mux and render layers.
The renderer now knows to omit the cursor when it is not visible.
1f81a064ed added support for noticing
that the dpi scale was not 1 on startup, but the timing of this
signal was different between the opengl and software renderers.
When using the software renderer, we'd end up computing a scaling
change with a pre-change pixel size but adjusted by a post-post
scaling factor, and that effectively caused the window to halve
its size on startup.
This commit improves things by also tracking the dpi in our locally
stored dimensions.
@jsgf suggested that it would be nice to have a degree of padding
around the terminal cells. This commit adds some plumbing for this;
```
[window_padding]
left = 10
top = 0
right = 10
bottom = 0
```
The left and top padding are used top compute the top-left coordinates
of the terminal cells. The right and bottom padding act as minimum
values; the actual padding used may be larger depending on the size
of the window and the number of cells that fit the available space.
top padding > 0 and the tab bar needs some work.
The ongoing saga from a465378dc4,
f204ad9a82, and others!
Only do scale adjustment here for glyphs that are taller rather than
wider.
This makes the ligatures in fira code look good again, and still
works with the v1 of the operator mono fonts.
@sunshowers requested a way to turn this off, so here's a top level
config option to control whether we perform ligature substitution.
Ideally this would be associated with the font rather than globally,
but threading that information through the various layers is more
difficult than a global setting.
@sunshowers mentioned to me that the window appeared blurry on a hidpi
display on startup, and was fixed by changing focus in a tiling window
manager.
I could replicate this using weston with scaling set to 2; the issue was
that the initial scale factor change event wasn't fully propagated and
bubbled up as a resize event to the terminal layer.
This commit taps into the dpi change event and forces it to be
interpreted as a window configuration change, resulting in more crisp
text.
Show the error message using a toast notification, but fall back to
the defaults; this makes it easier to get in and fix the issue,
rather than silently failing.
This is useful when launched from a gui launcher and the stderr is
not conveniently visible.
If a panic occurs, generate a toast notification with the panic
message so that there is a breadcrumb to follow if the application
does terminate in this way.
Every so often I encounter this situation on my windows machine during
a graphics card driver update, so this should help to run that down.
Adds the following options for the top level configuration,
which allow manipulating the quality of hinting and AA that
occurs for freetype:
```
font_antialias = "Subpixel" # None, Greyscale, Subpixel
font_hinting = "Full" # None, Vertical, VerticalSubpixel, Full
```
Refs: https://github.com/wez/wezterm/issues/79
The move to anyhow changed the nature of the error objects
that get passed through to the notification system; since
we use the `context` method and used the normal display
presentation (via `to_string`) we were only reporting the
context and not the nature of the error.
Switching to alternate output makes the error messages more
useful by including the underlying problem and line number.
Refs: https://github.com/wez/wezterm/issues/78
