Replace libayatana-appindicator with native D-Bus StatusNotifierItem implementation

[Copilot]

libayatana-appindicator (GPL-3.0) caused three compounding problems: GPL license contamination risk for downstream users, binary ABI incompatibilities across distros, and build failures in network-restricted packaging environments. The underlying functionality is just the StatusNotifierItem D-Bus spec, which can be implemented directly.

Approach

GDBus (GLib/GIO) is already a transitive dependency of gtk+-3.0, so this adds zero new dependencies.

Changes

• src/platform/linux/tray_icon_linux.cpp — Full rewrite:

  • Registers a D-Bus object at /StatusNotifierItem implementing org.kde.StatusNotifierItem
  • Exposes all required SNI properties including IconPixmap (GdkPixbuf → ARGB32 network-byte-order conversion), Title, ToolTip, Status
  • Maps D-Bus method calls to existing events: Activate → TrayIconClickedEvent, SecondaryActivate → TrayIconDoubleClickedEvent, ContextMenu → TrayIconRightClickedEvent
  • Registers with both org.kde.StatusNotifierWatcher (KDE/Plasma) and com.canonical.StatusNotifierWatcher (Ubuntu/GNOME) with graceful fallback
  • OpenContextMenu() uses PositioningStrategy::CursorPosition() to pop the GTK menu at pointer position
  • Thread-safe SNI instance indexing via std::atomic<int>

• src/platform/linux/tray_manager_linux.cpp — Removes all AppIndicator conditionals; IsSupported() probes D-Bus session bus availability (result cached)

• src/CMakeLists.txt — Drops ayatana-appindicator3-0.1 pkg-config module and its link target

• .github/workflows/build.yml — Removes libayatana-appindicator3-dev from the Linux CI install step

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Linux] libayatana-appindicator troublesome</issue_title>
<issue_description>Rewritten with explicit separation of problems, causes, and solutions.

---

Summary

The library libayatana-appindicator, currently used for Linux support, creates multiple issues for Linux distributions and downstream users. These issues fall into three main categories: packaging constraints, binary compatibility problems, and licensing risks.

In practice, these issues arise because the library is being used where a simple D-Bus implementation would suffice, and the current dependency chain introduces unnecessary complexity.

---

Issues

1. Packaging problems on Linux distributions

Using libayatana-appindicator is difficult for many Linux distributions due to their packaging policies and Flutter’s installation model.

Cause

Most distributions prohibit network access during package builds. Examples:

• Gentoo packaging rules:
  https://devmanual.gentoo.org/ebuild-writing/functions/src_test/index.html#tests-that-require-network-or-service-access

• Debian policy:
  https://www.debian.org/doc/debian-policy/ch-source.html

Required targets must not attempt network access during build.

However Flutter itself often expects:

• installation in writable directories
• downloading artifacts during build
• execution outside restricted environments

Flutter explicitly documents issues when installed in restricted locations:
https://docs.flutter.dev/install/troubleshoot#flutter-in-special-folders

Result

Package maintainers are forced to rely on prebuilt binaries rather than building from source.

---

2. Binary compatibility issues

Using prebuilt binaries introduces compatibility problems with system libraries.

Cause

The libayatana-appindicator libraries installed by distributions can vary in:

• file names
• ABI versions
• installation paths

Examples from typical installations:

/usr/lib64/libayatana-appindicator3.so
/usr/lib64/libayatana-appindicator3.so.1
/usr/lib64/libayatana-appindicator3.so.1.0.0
/usr/lib64/libayatana-ido3-0.4.so
/usr/lib64/libayatana-ido3-0.4.so.0
/usr/lib64/libayatana-ido3-0.4.so.0.0.0
/usr/lib64/libayatana-indicator3.so
/usr/lib64/libayatana-indicator3.so.7
/usr/lib64/libayatana-indicator3.so.7.0.0

Prebuilt binaries may:

• expect a different version of these libraries
• expect them in different paths
• link against incompatible builds

Additional complication

The library ecosystem has been forked and renamed multiple times, meaning different distributions may ship different implementations.

Examples:

• https://github.com/AyatanaIndicators/libayatana-appindicator
• https://github.com/AyatanaIndicators/libayatana-appindicator-glib

Distribution renames and compatibility issues:

• https://www.reddit.com/r/debian/comments/pn1oia/what_happened_to_libappindicator31_in_debian_11/
• https://unix.stackexchange.com/questions/701050/how-do-i-download-libappindicator1
• Debian 11 (testing) and libindicator (libayatana-indicator instead?) signalapp/Signal-Desktop#4866
• https://builds.openbuilds.com/threads/libappindicator3-1.18899/

---

3. GPL licensing risk

A major issue is the license of the library.

libayatana-appindicator is licensed under GPL-3.0:
https://github.com/AyatanaIndicators/libayatana-appindicator/blob/main/COPYING

Cause

If a project links against a GPL library (including via FFI), the GPL's copyleft terms may apply to the entire program.

This can require the entire application to be distributed under GPL-compatible terms.

Result

This introduces a licensing contamination risk for downstream users, particularly those who wish to distribute closed-source software.

---

Root cause

After investigation, libayatana-appindicator does not provide complex functionality.

It is primarily an implementation of the StatusNotifierItem specification:

https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/

This specification simply defines a D-Bus interface for system tray indicators.

---

...

• Fixes [Linux] libayatana-appindicator troublesome #42

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.