This is necessary for applications spawned via wezterm to be able to
generate apple events.
wezterm already had the text for the authorization prompt in its plist,
but because it was code signed with the default set of entitlements,
macOS didn't bother to prompt.
This commit introduces an explicit set of entitlements and uses those
when signing the executable.
I test this by manually codesigning on my laptop and confirmed that I
could run bbedit from inside wezterm.
I can't directly test the CI version of that flow on my laptop as it may
destroy my keychain if I got something wrong.
We'll have to see if the CI generated build works out!
refs: https://github.com/wez/wezterm/issues/2242
h/t to https://github.com/microsoft/vscode/issues/119787 for
clearly documenting what was needed.
Right now the initial x11 appearance retrieval uses the specific
connection interface, which completely circumvents the already existing
more complete implementation in x_and_wayland.rs.
The latter implementation is strictly better, because it first attempts
getting the appearance from the XDG desktop portal and then falls back
to the X11 interface.
Before this patch there was a very weird issue for folks using the OS
system dark mode with the following config snippet:
```
color_scheme = scheme_for_appearance(wezterm.gui.get_appearance())
```
The color_scheme on startup would be correct, but there would be a very
weird problem where sometimes wezterm ignores the first time that the
portal notifies about an appearance update.
The source of the bug was an inconsistent retrieval of the appearance
setting:
- The Lua API used the XDG desktop portal
- The internal appearance used the X11 specific connection at startup
For example due to this, the internal appearance variable could have
stored "Dark" from the X11 connection, but the actual appearance from
the XDG desktop portal was "Light".
If then the XDG desktop portal changes to "Dark", the
appearance_changed() method would dismiss the update because
self.appearance was already "Dark".
It is only after that, that the internal inconsistency would have been
solved and following appearance changes would succeed and update the
colorscheme correctly.
To fix this problem, we now use the portal directly in both the x11 and
wayland connections, which is consistent with the Lua
wezterm.gui.get_appearance() API.
refs: #2258
This simplifies the "change scheme based on dark mode" example
a lot. This was previously impossible to do because we didn't
have a lua module associated with the gui until recently, so
the only way to reference a gui-related object was via an
event callback.
refs: https://github.com/wez/wezterm/issues/2258
Record the version in which we first saw a color scheme.
For schemes from iterm2-color-schemes, we just assume that
we've had them forever as it isn't easy to reverse engineer
that metadata.
Everything else is tagged as 'nightly builds only' and I'll update
that to match the version number in the next release.
Newly discovered items will be added with 'nightly builds only'
from this point onwards.
Originally I had names like `base 16:foo` but wanted `foo` to
sort with `f` rather than `b`, so this prefix extraction
handled that.
I later changed the names to be `foo (base 16)` so we don't
need this.
This moves the `X::Erosion` scheme to sort under `x` where it
feels more natural.
Ensure that scheme_data.rs has a deterministic sort order that
matches the json data.
It can be confusing to see the same log lines when re-opening
the debug overlay, so this commit remembers the last line
in a global to make that feel more natural.
Because that causes the initial `OpenGL Initialized!` log to
show only in the first instance of the overlay, that log line
is now changed to debug level and the overlay will now
explicitly log the version information, along with some
brief usage text:
```
Debug Overlay
wezterm version: 20220714-001416-810512c2
OpenGL version: AMD BEIGE_GOBY (LLVM 14.0.0, DRM 3.46, 5.18.10-200.fc36.x86_64) 4.6 (Compatibility Profile) Mesa 22.1.3
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
```
Adjust importer to read directly from the source .itermcolors
files in the upstream repo. Extract some author information
from the comments in those files.
All data is now fetched (and cached!) via relatively minimal
http requests rather than requiring a git repo locally.
Also search for .yml files in base16 repos; found another
couple of schemes this way.
The toml files under assets/colors are no longer read by
anything in the repo. I plan to remove them, but since the
docs reference them as examples, I will first ensure that
there are docs and tooling that explains how to write and
share your own scheme files.
Querying the window can call into windowproc so we need to avoid
it when we hold `inner`. Adjust the flow so that we can get
the info about the window state purely from an HWND.
refs: #2257
Attach the mux events to the frontend workspace reconciliation function
so that the window is updated to match the new workspace.
Ensure that we correctly clear out any overlay panes as part of the
switch: we need to remove them from the mux so that the mux will
correctly identify that the mux is empty when the main panes from
the workspace are closed. The problem case was that the debug overlay
state was forgotten by the gui when activating the new workspace, but
we didn't tell the mux to kill it off, so subsequently CTRL-D'ing
the windows closed the windows but left the wezterm process running with
no head.
refs: #2248
It's now possible to specify a validation function for config
items.
Use that to validate line_height:
```
; ./target/debug/wezterm --config line_height=-1
08:41:10.576 ERROR wezterm > Error converting lua value from overrides to Config struct: Error processing Config::line_height: Illegal value -1 for line_height; it must be positive and greater than zero!; terminating
```
refs: https://github.com/wez/wezterm/issues/2247
We don't really know which of the on-screen matches the user was
looking at when they selected the text, but assume that the one
nearest the bottom of the viewport is the one they want to select,
rather than the one closest to the top.
refs: https://github.com/wez/wezterm/issues/2250
