launching GTK apps on MacOS+homebrew (revenge of $XDG_DATA_DIRS)

[mitchblank]

Sorry if this is a dup of any other discussion. I found several things which were close to this, but nothing that captured this problem exactly.

Background:

• ghostty sets $XDG_DATA_DIRS; in order to not break other programs it prepends what it thinks the default value will be: see Setting XDG_DATA_DIRS breaks various GTK-based programs #2711 This presumably works on linux.
• It sets this environment variable on MacOS too: macos: add our application bundle to XDG_DATA_DIRS #2974
• However, when installing GTK apps via other software managers like homebrew, the default $XDG_DATA_DIRS isn't the same as it would be on linux. (I'm guessing this is relative to --prefix that GTK itself was compiled with?)
• Complicating this, the location on MacOS depends on what software manager(s) are in use. See this comment in some Inkscape code: https://gitlab.com/inkscape/inkscape/-/merge_requests/3072/diffs

The end effect is that GTK apps (in my case, virt-manager) break when started from ghostty:

$ virt-manager

(virt-manager:43636): GLib-GIO-ERROR **: 03:03:56.257: No GSettings schemas are installed on the system
[1]    43636 trace trap  virt-manager

If I manually add $HOMEBREW_PREFIX/share to the front of $XDG_DATA_DIRS it works:

$ XDG_DATA_DIRS=/opt/homebrew/share:$XDG_DATA_DIRS virt-manager

So basically, virt-manager (and probably other GTK apps) built on homebrew work with an unset $XDG_DATA_DIRS, but not with one that is set but missing its bits.

Right now ghostty's default $XDG_DATA_DIRS seems to be hardcoded:

ghostty/src/termio/Exec.zig

Line 810 in bee2188

env.get(xdg_data_dir_key) orelse "/usr/local/share:/usr/share",

I don't know if there is a great solution that would work in all cases, but at least on MacOS that should probably include /opt/homebrew/share if it exists. That wouldn't solve the problem in general for other software managers (or non-default homebrew installs) but at least it would cover a lot of people.

On linuxbrew it seems use /home/linuxbrew/.linuxbrew/share per Homebrew/brew#18317

Maybe just probing for some of these common "share" locations would solve the problem well enough?

[rhodes-b]

ghostty on mac os does not use GTK it uses native swift ui. I didnt read enough ill let someone else handle this I dont have a mac so I cant speak for anything

[mitchblank]

Yes, just to be clear: this has nothing to do with what toolkit Ghostty itself is using. It just comes down to:

• Ghostty sets $XDG_DATA_DIRS
• Other apps (GTK for sure, maybe others) will break if it's set wrong
• Setting it "right" is not trivial... maybe not even possible in the fully-general case. Normally on linux it's usually a good bet that all of the OS-provided apps will be happy with the default ghostty is providing... but things like linuxbrew might break that. On MacOS/intel homebrew /usr/local/share is the default location, but MacOS/aarch64 homebrew defaults to /opt/homebew/share. Then there is MacPorts which might do something else entirely, etc, etc...

My personal suspicion is that setting $XDG_DATA_DIRS at all was the original sin here. Since ghostty can have any binary as a child process, any setting you choose needs to work for all of them! Probably it's going to always cause problems for a terminal emulator to touch it. However, I don't know well enough why ghostty decided to set it in the first place, so I can't really judge the decision.

[mitchellh]

We set the default based on the XDG specification, namely:

If $XDG_DATA_DIRS is either not set or empty, a value equal to /usr/local/share/:/usr/share/ should be used.

This feels like it's a bug in the Homebrew formula for GTK or GTK itself where it should be exporting additional data dirs into your shell.

[mitchblank]

Digging into it more:

A few months ago, Homebrew did start to set $XDG_DATA_DIRS itself, although only on Linux: Homebrew/brew#18326

HOWEVER, they had to immediately revert it ( Homebrew/brew#18677 ) because it caused different problems , see Homebrew/brew#18643 (comment)

For awhile the diagnostic tool brew doctor will at least complain if $XDG_DATA_DIRS was set and did not include Homebrew's share/ directory (again, only on linuxbrew) but even that caused problems and was soon removed: Homebrew/brew#18680

Not 100% sure why these attempts were linux-only BTW; maybe running GTK apps on MacOS is rare enough that it didn't cause complaints? I use virt-manager installed from Homebrew, though, so it definitely has some impact on MacOS as well.

So I agree that in theory packagers that must put resources in non-standard places update $XDG_DATA_DIRS, it sounds like that was tried already and caused other serious problems. :-(

[jdloft]

I'm a little curious as to how GTK apps are finding the resources in the first place if $XDG_DATA_DIRS isn't set. If I unset the variable, GTK apps work fine.

Is there a config file somewhere that's dictating the default behavior that homebrew is setting? I would think unsetting $XDG_DATA_DIRS would break things as well if it were the single source of truth.

[torque]

I have run into this problem with vulkan-loader installed through homebrew as well (in my case it caused mpv being launched from ghostty to fail to initialize its video output). Looking at the formula, it has the compile flag:

-DFALLBACK_DATA_DIRS=#{HOMEBREW_PREFIX}/share:/usr/local/share:/usr/share

Although I cannot prove this is how this works, it sure seems like it probably does essentially the same thing that ghostty does, i.e. substitutes in that particular value only when the environment variable is not defined, and only uses the paths from the variable when the variable is defined.

Adding the homebrew path to XDG_DATA_DIRS is in theory straightforward, but at least when using fish (I can't speak to other shells), doesn't actually work as expected. In fish, you'd normally do something like

set -Ux --path XDG_DATA_DIRS $HOMEBREW_PREFIX/share /usr/local/share /usr/share

in order to export a universal variable that is available to all shells. The problem seems to be that, as a graphical application, ghostty does not launch from the shell environment. The ultimate outcome of this is that ghostty actually clobbers my shell configuration. It is possible to modify config.fish to add

set -gx --path XDG_DATA_DIRS $HOMEBREW_PREFIX/share /usr/local/share /usr/share

So that fish will overwrite the variable that ghostty overwrote, but that is kind of kludge, and is not very fish-like.

Another way to work around this, sort of, is by running

launchctl setenv XDG_DATA_DIRS $HOMEBREW_PREFIX/share:/usr/local/share:/usr/share

and then restarting ghostty, but that does not get preserved across reboots (or probably even logouts). Also, this may only work if ghostty is launched through spotlight rather than from the dock.

In any case, the way this currently works seems to be a pretty subpar out-of-the-box experience. I certainly would not expect ghostty to be clobbering my fish variables, and it seems like it breaks a variety of homebrew packages.