You are not logged in.
In my system I have user's at-spi-dbus-bus.service masked because I don't use it. GTK4 didn't like that and complained:
$ gtk4-demo
(gtk4-demo:9554): Gtk-WARNING **: 03:09:29.946: Unable to acquire the address of the accessibility bus: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer 'org.a11y.Bus': activation request failed: unit is masked. If you are attempting to run GTK without a11y support, GTK_A11Y should be set to 'none'.
So I set "GTK_A11Y=none" in /etc/environment (~/.config/environment.d/ works as well). GTK4 is happy, me too. However, xterm >= 400 trims down a bunch of environment variables including GTK_, so running GTK4 applications from xterm still leads to that annoying message.
There are several potential options to solve the issue:
* Give up and enable that freaking a11y.
* Re-set GTK_A11Y in /etc/bash.bashrc or ~/.bashrc - this doesn't look like good solution because environment variables should not be set on every shell invokation.
I would ask author of xterm regarding necessity to trim down GTK_ variables (neither changelog nor commit message explain that). However, I'd like to know first, maybe there is obvious reason for trimming GTK_ variables, or I'm wrong with my system configuration. Any suggestions?
Last edited by dimich (2025-10-10 01:00:49)
Offline
https://docs.gtk.org/gtk4/running.html
https://docs.gtk.org/gtk3/running.html
https://www.manpagez.com/html/gtk2/gtk2 … unning.php
I understand why you'd clear environments that might mislead processes about the running TE, but the GTK_ thing makes no sense to be (maybe TED was just annoyed by GTK_DEBUG )
Is "NO_AT_BRIDGE" no longer checked by GTK4?
Edit: https://github.com/ThomasDickey/xterm-s … in.c#L3928 looks iffy - tmux checks for nested invocation (and warns you by default because that's likely an EBKAC)
Last edited by seth (2025-10-10 08:09:09)
Offline
Is "NO_AT_BRIDGE" no longer checked by GTK4?
NO_AT_BRIDGE is checked by at-spi itself but doesn't prevent GTK from connecting to its bus, so at-spi-dbus-bus.service still needs to be running.
Edit: https://github.com/ThomasDickey/xterm-s … in.c#L3928 looks iffy - tmux checks for nested invocation (and warns you by default because that's likely an EBKAC)
This doesn't seem to be an issue because nested invocation implies the same terminal. If tmux is invoked from xterm running from another tmux, it's in a new terminal. However, there may be other pifalls.
Offline