如何通过PyGTK的AppIndicator3检测Linux托盘图标的鼠标点击事件

该能力的缺失本质是底层规范设计的约束，而非AppIndicator3框架本身的功能阉割：

• AppIndicator3完全基于Linux桌面通用的StatusNotifierItem（SNI）D-Bus规范实现，从规范设计之初，就将托盘左键点击的默认交互权限划给了托盘宿主（GNOME Shell、KDE Plasma的托盘组件），定义的默认行为是“点击左键自动弹出应用绑定的菜单”，根本没有在透传信号层单独开放“原始左键单击事件”给应用进程。
• 你已经接触到的两个能力都是规范明确定义的透传接口：scroll_event对应SNI规范的Scroll信号，set_secondary_activate_target对应SNI规范里定义的、会直接透传给应用的中键点击SecondaryActivate方法，这两个是少数不受宿主托管的可透传事件。

• 直接继承AyatanaAppIndicator3.Indicator类重写本地事件处理逻辑是无效的：整个类的事件流转不存在本地进程内的X11/Wayland鼠标捕获流程，所有交互事件都是宿主通过D-Bus远程发送过来的，本地重写Gtk类的事件回调根本收不到任何鼠标触发信息。
• 直接绕开Python绑定层对接SNI规范的D-Bus接口是完全可行的：
  • SNI规范本身确实定义了Activate(x, y)方法作为左键点击的透传入口，只是AppIndicator3的Python绑定层把这个接口的默认逻辑写死成了“收到Activate就弹绑定菜单”，没有把原始回调暴露给用户。
  • 双击检测没有任何规范层的原生支持，完全可以在应用层实现：当收到两次Activate回调的时间间隔小于300ms时，即可判定为双击，其余情况判定为单击，和Qt实现双击唤起窗口的逻辑完全一致。
  • 该方案的兼容性注意点：不同桌面宿主对Activate方法的触发逻辑不统一——GNOME Shell是收到Activate回调后再执行弹菜单动作，KDE Plasma是弹完菜单再触发Activate回调，部分精简版桌面甚至不会主动触发Activate，直接自行弹菜单就结束流程。

• 隐藏菜单项间接绑定方案
  利用现有AppIndicator3对中键事件的透传能力，给指示器绑定一个无可见UI的隐藏菜单项，把自定义单击动作绑定到该菜单项的activate信号上；同时监听绑定的Gtk.Menu的show/hide信号，判断弹出动作是否是宿主正常触发的菜单弹出，如果是正常菜单弹出就不执行自定义逻辑，否则响应隐藏菜单项的点击动作。该方案在X11环境下可稳定运行，Wayland下因为跨进程读取窗口状态的权限限制，会出现菜单显隐检测失效的问题。
• 纯D-Bus直连实现方案
  完全绕开AppIndicator3的Python绑定，通过dbus-service直接在Session Bus上注册符合SNI规范的自定义托盘实例，自行实现Activate、SecondaryActivate、Scroll三个接口的回调逻辑：收到Activate回调后自行判断单击/双击，完全自主决定后续是弹菜单、唤起主窗口还是执行其他自定义动作，仅在需要显示菜单时按照SNI的坐标协议把菜单位置传给宿主要求弹出。该方案可以拿到最灵活的事件控制权，但是需要自行适配不同桌面的托盘兼容性规则。
• 保底过渡方案
  对兼容性要求高的场景，可以先把“双击唤起主窗口”的逻辑绑定到已经能稳定触发的中键SecondaryActivate事件上，作为Wayland环境下的保底交互，不用等待规范层的原生支持。

注：网传的“AppIndicator完全不支持自定义单击动作”的结论，本质是没有绕开Python绑定层的默认硬编码逻辑，而非底层完全无法实现。

内容的提问来源于stack exchange，提问作者BlueManCZ