24 Commits

Author SHA1 Message Date
Mitchell Hashimoto
5306e7cf56 config: add launched-from to specify launch source
Related to #7433

This extracts our "launched from desktop" logic into a config option.
The default value is detection using the same logic as before, but now
this can be overridden by the user.

This also adds the systemd and dbus activation sources from #7433.

There are a number of reasons why we decided to do this:

  1. It automatically gets us caching since the configuration is only
     loaded once (per reload, a rare occurrence).

  2. It allows us to override the logic when testing. Previously, we
     had to do more complex environment faking to get the same
     behavior.

  3. It forces exhaustive switches in any desktop handling code, which
     will make it easier to ensure valid behaviors if we introduce new
     launch sources (as we are in #7433).

  4. It lowers code complexity since callsites don't need to have N
     `launchedFromX()` checks and can use a single value.
2025-06-02 08:45:02 -07:00
Mitchell Hashimoto
0f4d2bb237 Lots of 0.14 changes 2025-03-12 09:55:52 -07:00
Mitchell Hashimoto
ebffe299ce macOS: only set LANGUAGE for app bundle, do not inherit in termio env
Fixes #6633

For macOS, we set LANGUAGE to the priority list of preferred languages
for the app bundle, using the GNU gettext priority list format (colon
separated list of language codes).

This previously was inherited by the termio env. At first, this was by
design, but this has inherent flaws. Namely, the priority list format is
a GNU gettext specific format, and programs that use alternate gettext
implementations (like musl or Python) do not understand it and actually
do the wrong thing (not their fault!).

This change removes the inheritance of LANGUAGE in the termio env. To
make it extra safe, we only do set and unset LANGUAGE when we know we
launch from an app bundle. That was always the desired behavior but this
makes it more explicit.
2025-03-09 18:17:38 -05:00
Mitchell Hashimoto
78f16d040d macOS: disable setting LANGUAGE for now until bug is fixed
See: https://github.com/ghostty-org/ghostty/discussions/6633

This is temporary while we figure this out.
2025-03-09 07:25:55 -07:00
Mitchell Hashimoto
b48fcf33f7 macOS: Set LANGUAGE env var based on macOS preferred language list
Sets the LANGUAGE environment variable based on the preferred languages
as reported by NSLocale.

macOS has a concept of preferred languages separate from the system
locale. The set of preferred languages is a list in priority order
of what translations the user prefers. A user can have, for example,
"fr_FR" as their locale but "en" as their preferred language. This would
mean that they want to use French units, date formats, etc. but they
prefer English translations.

gettext uses the LANGUAGE environment variable to override only
translations and a priority order can be specified by separating
the languages with colons. For example, "en:fr" would mean that
English translations are preferred but if they are not available
then French translations should be used.

To further complicate things, Apple reports the languages in BCP-47
format which is not compatible with gettext's POSIX locale format so
we have to canonicalize them. To canonicalize the languages we use
an internal function from libintl. This isn't normally available but
since we compile from source on macOS we can use it. This isn't
necessary for other platforms.
2025-03-08 12:54:39 -08:00
Mitchell Hashimoto
dcb8440b52 os: remove the preferredLanguages lookup 2025-03-07 13:43:00 -08:00
Mitchell Hashimoto
3c49bc5086 os: locale automatically sets LANGUAGE based on macOS preferred 2025-03-07 13:42:00 -08:00
Mitchell Hashimoto
67dce5ce0e update zig-objc 2023-11-17 21:50:34 -08:00
Mitchell Hashimoto
ea5ff77e29 os: macos lang check should include lang null 2023-11-05 15:46:05 -08:00
Mitchell Hashimoto
8f35d5251e os: rename env to be posix-like, do not allocate on posix 2023-11-05 15:39:25 -08:00
kcbanner
9a5322eaf4 - Update libxev dependency
- Fixup macos compile error
2023-11-05 23:15:52 +00:00
kcbanner
232df8de8f windows: add support for the glfw backend on Windows
Changes:
- Add WindowsPty, which uses the ConPTY API to create a pseudo console
- Pty now selects between PosixPty and WindowsPty
- Windows support in Command, including the ability to launch a process with a pseudo console
- Enable Command tests on windows
- Add some environment variable abstractions to handle the missing libc APIs on Windows
- Windows version of ReadThread
2023-11-05 23:15:49 +00:00
Brandon Ferguson
17957b8fb3 If the locale isn't supported and falls back to the POSIX/C locale, use en_US.UTF8 2023-10-21 10:33:26 -07:00
Mitchell Hashimoto
d878d16779 os: unset lang completely setlocale fails 2023-09-29 13:11:07 -07:00
Mitchell Hashimoto
38a7c2270b os: we need to copy the old lang pointer before we unsetenv 2023-09-29 12:56:43 -07:00
Mitchell Hashimoto
0026c40062 Simplify setlocale logic to rely on libc to fail if invalid
Instead of checking if a locale is valid, let's change this logic:

  1. We first try setlocale to inherit from env vars, system default.
  2. Next, we fall back to unsetting LANG if it was set manually,
     allowing us to fall back to system defaults.
  3. We fall back to en_US.UTF-8.
2023-09-26 17:35:19 -07:00
Thorsten Ball
5472d03832 locale: remove default value for local dev env
I commented this out to test something locally and it compiles & runs
fine on macOS with Xcode. Looks like it's not needed anymore.
2023-07-19 06:46:01 +02:00
Thorsten Ball
4b48d42a07 locale: set LANG to the fallback value if we have invalid locale
See #201 for more information.

Problem is that while we fall back to a default value to pass to
`setlocale`, we don't set a `LANG` and instead reset it to `""`.

What this does here is it changes the resetting to `""` and instead sets
it to the default value.
2023-07-19 06:44:35 +02:00
Mitchell Hashimoto
4176c6bdbf reset LANG env var if we set it and it is invalid
This was breaking downstream programs, see #201
2023-07-18 10:49:43 -07:00
Mitchell Hashimoto
0849aa8f20 validate locale prior to setting, fallback to en_US.UTF-8
Fixes #201

I don't fully understand locales, but it appears that the locale
returned from NSLocale can be "valid" in general but invalid according
to libc's locale API. If you attempt to `setlocale` with this bad
locale, it defaults everything to "C", which ends up breaking a lot of
things.

This commit validates the locale, and if it is invalid, we default to
"en_US.UTF-8" so things tend to work. This behavior can be overridden
using standard environment variables (LANG, LC_ALL, etc.).

This also doesn't touch env vars so further subprocesses from the shell
see original locale env vars.
2023-07-11 11:50:12 -07:00
Mitchell Hashimoto
b3090f60af mac: in debug, set locale to en_US if not manually set
See comment, I think this is a Zig miscompilation...
2022-12-15 14:50:52 -08:00
Mitchell Hashimoto
56504a342f better commenting 2022-11-14 10:03:39 -08:00
Mitchell Hashimoto
20cbee5370 locale always requires libc 2022-11-14 10:02:48 -08:00
Mitchell Hashimoto
f39484541f set system locale on startup, read Mac locale from OS preferences 2022-11-14 09:59:22 -08:00