☰

绕行：X11

tag-icon • tag-icon d-bus accessibility
绕行：X11

当我从命令行运行 X 应用程序（例如 leafpad；大多数应用程序）时，我在控制台上收到以下警告：

 ... dbind-WARNING **: ... Couldn't register with accessibility bus: Did
not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the 
reply timeout expired, or the network connection was broken.

（断线以适应列宽。）

为什么我会收到此消息？我该怎么办？发布它的应用程序似乎运行良好。

这出现在 Ubuntu 18.04 和 Devuan 3.0 Beowulf (~= Debian Buster) 上

答案1

把这个：

export NO_AT_BRIDGE=1

它运行的某个地方，例如在/etc/environment或您的~/.bashrc/中~/.bash_profile。

此解决方法建议在这个维基页面（德语）或这里（英文），但我真的不明白为什么需要它或者它到底有什么作用，所以买者自负。

答案2

很高兴你自己找到了答案；这里有一些更多的背景来回答评论中的“为什么”。

我在这样的设置中遇到了这个错误。使用 2 台笔记本电脑（一台用于工作，使用 Kubuntu，另一台是我个人拥有的，使用 Arch）——我有点懒，没有拿起另一台笔记本电脑，而是使用X11转发又名ssh -X。

绕行：X11

从概念上讲，X11 转发是一种“远程桌面”技术，如 VNC、RDP……但有一些不同。它不执行远程桌面的视频流；相反，它采用 X11 协议的网络架构。

回到 X11 构想的时代（1980 年代！），所有屏幕和键盘是“远程”的：一个巨大的大型机柜正在运行支持许多用户的 GUI 应用程序的操作系统进程（通常是全部拥有该大型计算机的组织中的计算用户）。因此，在 X11 中，像素绘图部分是在客户端完成的。

  VNC-style remote desktop                              X11 forwarding
  ────────────────────────                              ──────────────

┌─────[Client machine]──────┐        ┌──────[Client machine]────────────────────────────────┐
│                           │        │                                                      │
│  Runs VNC viewer app      │◄──┐    │ - Runs X server                                      │
│                           │   │    │ - Runs local GUI apps, i.e. those using DISPLAY=:0   │
│  • remote GUI embedded in │   │    │ - Renders remote GUI apps which X11-connect to it,   │
│    VNC viewer window      │   │    │   to network address like  client.local.lan:0        │
│                           │   │    │   Usually nowadays, ssh -X secures the X11 traffic   │
└───────────────────────────┘   │    │   by tunnelling it; so e.g. DISPLAY=localhost:10.0   │
                                │    │   This localhost is interpreted by app running on    │
                         network│    │   the server machine!                                │
                                │    │   Because SSH tunnel.             ┌─────┐   ┌─────┐  │
┌─────[Server machine]──────┐   │    │                           ┌──────►│ GUI │ … │ GUI │  │
│                           │   │    ├───────────────────┐◄──────┘       └─────┘   └─────┘  │
│  Runs VNC server app      │◄──┘ ┌─►│ SSH tunnel egress │                local X11 server  │
│                           │     │  └───────────────────┴──────────────────────────────────┘
│  • streams pixels of the  │     │
│    entire screen          │     │  ┌──────[Server machine]────────────────────────────────┐
│  • receives client input, │     │  │                                                      │
│    forwards it to GUIs    │     │  │ - May lack any screens, input devices, GPUs          │
│                           │     │  │ - May not run any X server                           │
│ ┌─────────┐   ┌─────────┐ │     │  │ - Yet, runs remote GUI apps, as OS processes         │
│ │ GUI app │ … │ GUI app │ │     │  │ - GUI stuff lives on client machine's X server       │
│ └─────────┘   └─────────┘ │     │  │ - Painting commands and input events                 │
│                           │     │  │   travel within the X11 connection.                  │
└───────────────────────────┘     │  │                                                      │
                                  │  │                                   ┌─────┐   ┌─────┐  │
                                  │  │                           ┌──────►│ app │ … │ app │  │
                                  │  ├────────────────────┐◄─────┘       └─────┘   └─────┘  │
                                  └─►│ SSH tunnel ingress │                 OS processes    │
                                     └────────────────────┴─────────────────────────────────┘

在个人计算机的常见用例中，X 服务器和客户端 GUI 运行在同一台计算机上，因此这个有趣的 X11 协议在本地主机上运行时几乎是不可见的。

但它也可以在真实网络上运行，而且效果出奇的好！特别是如果辅以 ssh 的内置压缩功能，-C.例如，我可以使用“远程”运行 Brave（基于 Chromium 的网络浏览器）ssh -CX pasocon.local brave，并且它几乎可以通过 WiFi 使用。

Detour：Linux 桌面上的可访问性

不多说了，不是专家，一点也不熟悉。但我要说两件事。

首先，观察 X11 转发架构原则上更适合辅助技术。例如，屏幕读取远程桌面的原始视频流（尽管人工智能技术有一天可能会解决这个问题）比屏幕读取 X 服务器状态或事件/命令流更具挑战性。通过 X11 协议，应用程序会说嘿 X 服务器，在这些坐标处以这种字体绘制文本“Lorem ipsum”；改变这个按钮的颜色；折叠此菜单， ETC。

其次，请注意大多数围绕 VNC/RDP 风格处理嵌入式桌面输入的恶作剧（焦点抓取、特殊组合键的转义，如 Ctrl-Alt-Del、正确重新映射键盘布局、剪贴板等）只是简单地进行离开 X11 转发。在客户端计算机上，远程 GUI 实际上是尽可能的“本地”。我的 KDE Plasma 甚至无法区分 X11 转发肉桂Alt-Tab 界面中的本地 KDE 窗口。

绕道：Freedesktop D-Bus

简而言之，D-Bus 是一个面向对象风格的 RPC（远程过程调用）框架。它在 Linux 桌面上广泛使用（但不仅限于此）。对于某些示例，NetworkManager 提供 dbus 服务；编写一个通过 dbus 与之通信的应用程序来查看和操作这些网络连接，或者在系统连接发生变化时获取回调相对容易。桌面通知（来自电子邮件、即时通讯工具、浏览器应用程序等的弹出窗口）是一项广泛集成的org.freedesktop.NotificationsD-Bus 服务。 Ayatana Indicators（托盘图标）也可以通过 D-Bus 工作。还有更多。

在 D-Bus 上提供无障碍辅助技术的扩展点也是非常有意义的。

在编写了与 D-Bus 配合使用的代码后，我可以 100% 毫无疑问地判断，此错误消息涉及 D-Bus 方法调用失败：

...远程应用程序未发送回复、消息总线安全策略阻止了回复、回复超时已过期或网络连接已断开。

结合以上， 我能猜到为什么 export NO_AT_BRIDGE=1对我的情况有帮助。我正在将 Cinnamon（GNOME 衍生品）应用程序 X11 转发到 KDE 桌面。期望两个桌面的 D-Bus 实例能够神奇地连接是愚蠢的，据我所知 X.Org 并未耦合到 D-Bus。因此，我在 GTK 的“AT_BRIDGE”（AccessibilityToolkit Bridge？）中遇到了一些不起眼的极端情况......无论那是什么。禁用它可以解决我的问题。

当然，不确定这在多大程度上适用于原始问题中的问题。但是，这就是关于明显相关的移动部件的一些背景信息。华泰

相关内容