base arch linux installation doesn't include `hostname` binary as it's part of
a separate `inetutils` package, use systemd `hostnamectl` which is available in
all systemd-based distributions
Implement an app delegate to receive a callback when the system
requests that we open `.command` files, and then ask the mux
layer to spawn a window for it and execute it via the shell.
Also allow handling `.sh`, `.zsh`, `.bash`, `.fish` and `.tool`,
per kitty.
refs: https://github.com/wez/wezterm/issues/2741
refs: https://github.com/wez/wezterm/issues/2871
In a56904e40d the desktop file was patched
to use "wezterm start" instead of "wezterm". As an unneeded addendum
that patch also included the unnecessary addition of ending command-line
parsing by passing the "--" option at the end.
As it turns out, some consumers of wezterm's desktop file want wezterm
to parse command line flags. For example KDE's kio passes the whole
cmdline via the "-e" flag, because it is widely used for most terminal
emulators as the primary mean of passing the cmdline.
To solve this we remove the unneeded "--" again, because we now also
support the "-e" option.
After all, all trailing arguments will automatically be parsed by
wezterm as the cmdline of the program to run.
The only sideeffect of this change is that we now cannot longer start
programs that share a name with a "wezterm start" option, for example if
the user has installed an executable at /usr/bin/--always-new-process
then this edge case will not work anymore.
Given that this would be an extremely unlikely scenario, it makes more
sense to improve compatibility by supporting the usecase of passing the
cmdline with the "-e" flag.
refs: #2622
refs: #2271
refs: https://bugs.kde.org/show_bug.cgi?id=459616
As explained in the comments, the Nautilus 4.0 API just passes files without the window object (which was unused anyway). This small fix keeps compatibility with the 3.0 API and checks the number of arguments.
Would be really nice if you could make this count towards hacktoberfest as well!
I was going to upgrade to the unicode 15 font, but in testing this I
decided that the logic is slightly complex and the glyphs are often
difficult to see at most terminal font sizes, which generates questions
from users, so just fall back to notdef.
They pass this:
```
flatpak run --env=G_DEBUG=fatal-criticals org.freedesktop.appstream-glib validate assets/wezterm.appdata.xml
assets/wezterm.appdata.xml: OK
```
but break when building a flatpak
This commit allows wezterm to spawn programs into the host rather
than in the container environment.
It feels weird that it is so trivial to "break out" of the container
sandbox, but I'm not complaining.
There are some unfortunate consequences:
* there is no `wezterm` installed on the host, so no ability to `wezterm
cli` to control it from other apps
* The unix domain socket is scoped inside the sandbox, so there's "no
way" for `wezterm cli` to reach inside anyway.
But: with this, it is at least usable to start a flatpak and open a
shell.
refs: https://github.com/wez/wezterm/issues/2229
Run `ci/flatpak.sh` to build a flatpak of just the gui.
Run it via flatpak run org.wezfurlong.wezterm
refs: https://github.com/wez/wezterm/issues/2229
Thanks to: @Imxset21
The .deb package registers that script as the alternative for
a terminal emulator in the hope that various "open terminal here..."
functions in other tools will use that to detect wezterm and run
thing in the cwd.
refs: https://github.com/wez/wezterm/issues/2103
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.
Built using:
```
./FontForge-2020-11-07-21ad4a1-x86_64.AppImage --script $PWD/font-patcher "$PWD/src/unpatched-fonts/NerdFontsSymbolsOnly/NerdFontsSymbolsOnly Template 1000 em.ttf" --powerline --use-single-width-glyphs -out /tmp/nerd-fonts-out --fontawesome --fontawesomeextension --fontlinux --octicons --codicons --powersymbols --powerline --powerlineextra --mdi --weathericons
```
which is everything *except* Pomicons at the time of writing, pending
clarifications of its distribution license
(https://github.com/ryanoasis/nerd-fonts/issues/266)
refs: https://github.com/wez/wezterm/issues/1521
The default we use on macOS looks decent. Roboto is a similar
looking font that we can use for the other platforms.
I may make it the same on all three once I've had a chance
to compare it on a mac.
This commit switches back to wezterm-icon.svg as the source of
the icon, but modifies it:
* Removed mac style title bar + window manipulation icons
* Increases the corner radius
* Adjusts the text position and size
This makes it somewhere between the original and one of the alternate
icons in 98b71cbfb6
I chose to modify the original source as it didn't have padding
baked into the svg file, and I didn't feel like wrestling with
the contributed svg in inkscape to remove it.
