in https://github.com/wez/wezterm/issues/767 CTRL-Tab was getting
incorrectly normalized to CTRL-i; that normalization is valid (Tab is
actually equivalent to CTRL-i as far as unix terminals are concerned)
but unwanted at this layer.
I suspect that this change will come back to haunt me in the future,
as keyboard input is a bit of a zoo.
At the bottom of https://github.com/wez/wezterm/issues/815 is some
discussion about an apparent hang.
Let's make the self pipe writing a bit more robust and log to see
if that might be related.
In an earlier incarnation we needed to wake up more often to paint,
but we now should have reliable event sources for all of the
invalidation cases and we can thus sleep for much longer in
the main event loop.
refs: #770
When a window is being destroyed we expect the receiver end
to be disconnected, so we don't want to break out of the
message loop if a couple of residual windows fail to notify.
Removes the callbacks type and replaces event dispatch with
an async capable channel.
This makes it a bit simpler to model some of the window internals,
and to prepare for a wgpu enabled future.
This changes have been tested only on linux so far.
This should help us reason about whether a resize respected
our request.
This may break linux and windows builds, will fixup once
this is pushed.
refs: https://github.com/wez/wezterm/issues/695
We were getting abs() of the backing-rect-adjusted value, so we need to
restore the sign to avoid what should be logically cell position "-1"
being treated as cell position "1" and so on.
With this change, the logic in the gui layer successfully clamps the x
coordinate to zero when trying to drag left off the window.
NSCursor hide/unhide must be perfectly balanced otherwise
the cursor can vanish unexpectedly when the mouse leaves
the window, and not come back.
So, let's use NSCursor:setHiddenUntilMouseMoves instead; it's
not 100% fulfilling the promise of the API, but it's close enough
and should avoid the permanent invisibility issue.
refs: https://github.com/wez/wezterm/issues/618
This commit allows the x11 window implementation to detect changes
in the DPI that occur after a window is created.
These can occur when changing desktop resolution or when changing
the accessibility option for "Large Text" in gnome.
In order to avoid continually polling for the value on every resize,
we look for the `_GTK_EDGE_CONSTRAINTS` atom in our property change
notifications. This seems to be sent at least as often as the
dpi/scaling changes.
It's also worth noting that some dpi changes don't generate resize
events, so we can't just read the dpi value on every resize, because
we'd miss some of those changes.
Part of this commit changes the font scaling logic: previously
we'd keep a notion of "dpi scale" to apply. That dates from an
earlier time in wezterm where we didn't think that we knew an
actual dpi value.
The way that worked was that we'd compare our current guestimate
of the DPI against what we though the baseline OS dpi should be to
produce a scaling factor.
On X11 that dpi value is global and we'd effectively always produce
a revised scaling factor of 1 after we'd set up the initial window.
This commit changes that logic to just pass down the actual DPI value
to the font code. That DPI value already accounts for HiDPI scaling
so this is hopefully a NOP change for the other systems.
refs: https://github.com/wez/wezterm/issues/667
On macos, once all panes were closed, the GUI would request that the app
stop, but it wouldn't actually exit until a UI event occurred.
This was mostly noticeable when running debug builds from another
terminal.
Calling NSApp::abortModal is sufficient to knock us out of that state.
