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
When evaluating an assignment expression like `foo = "bar"` the result
of the expression is nil and we'd print nil on the next line,
which often startles me as I'm used to other languages where the
result of such an expression is the rvalue that was just assigned.
Let's just suppress nil when it is the result of an evaluation
in the repl for a cleaner look.
Moved the gradient function into the color module, but kept an alias
under the old name.
Gradients now return color objects.
Converting colors to string now uses rgba format when alpha is not 100%.
Otherwise we can block the gui waiting for eg: a freshly opened firefox to
terminate.
See also comment worrying about this in
75066cb522.
That fear was realized but now resolved!
refs: https://github.com/wez/wezterm/issues/2245
wezterm.color.parse() returns a color object that can be assigned in the
wezterm color config, and that can be used to adjust hue, saturation and
lightness, as well as calculate harmonizing colors (complements, triads,
squares) from the RGB/HSL color wheel.
I've been holding off from using UserData wrappers around things
because it is awkward to match them up with the To/FromDynamic
conversion.
This commit aims to help with that by implicitly calling the
tostring metamethod (if present) on a userdata both when printing
(so the values look reasonable in the repl) and when mapping a lua
value to a dynamic value.
Provided that the end type is try_from=String this will allow
the userdata value to be assigned as table value.
The intent is that when set, it changes defaults to something
more suitable for distributions.
I've also added a readme for distro maintainers.
refs: https://github.com/wez/wezterm/issues/1795
This commit expands the toml file definition to include
metadata for the origin url, author and name.
A new sync utility fills out that metadata when it pulls from the iterm2
color schemes repo.
The utility also pulls down the scheme data json maintained by
the Gogh project: https://gogh-co.github.io/Gogh/ and converts
it to wezterm's format.
About 50% of Gogh overlaps with iterm2; we take the iterm2 versions
of those schemes by default because the iterm2 data has more info
about things like cursor and selection colors.
The sync utility is responsible for compiling the de-duplicated
set of scheme data into a form that is used by wezterm and its
docs.
