Skip to content

unix: add SetIconTheme and SetIconThemePath for SNI icon theme support - #120

Open
vasyvasilie wants to merge 1 commit into
fyne-io:masterfrom
vasyvasilie:feature/icon-name-theme-path
Open

unix: add SetIconTheme and SetIconThemePath for SNI icon theme support#120
vasyvasilie wants to merge 1 commit into
fyne-io:masterfrom
vasyvasilie:feature/icon-name-theme-path

Conversation

@vasyvasilie

Copy link
Copy Markdown

Problem

On MATE desktop (with mate-indicator-applet) and some GNOME setups, the
StatusNotifierItem spec allows displaying the icon via IconPixmap (raw ARGB
data) or via IconName + IconThemePath (XDG icon theme lookup). Many
indicator applets on these desktops prefer IconName and either ignore or
poorly render IconPixmap.

Currently systray hardcodes IconName: "" and IconThemePath: "" as
non-writable properties in createPropSpec(), with no public API to change
them. There is also no way to make IconPixmap return an empty array — it
always calls convertToPixels(t.iconData) even when you'd rather have the DE
(Desktop Environment) fall back to IconName.

Real-world impact

I built an ap using Fyne + systray. The app switches tray icons between
two states. On MATE with
mate-indicator-applet:

  • IconPixmap is sent as a(iiay) with raw bytes, but the applet renders a
    blank/invisible icon
  • verified via busctl get-property that IconName = "" and
    IconThemePath = "" at all times
  • switching icons via systray.SetIcon(bytes) updates IconPixmap but the
    tray stays blank

The only working solution for MATE is:

# working state verified via busctl:
IconName:      "link"
IconThemePath: "/usr/local/bin/resources"
IconPixmap:    a(iiay) 0   ← empty, so DE uses IconName

Changes

  • SetIconName(name string) — sets IconName DBus property and emits
    NewIcon signal to notify the host
  • SetIconThemePath(path string) — sets IconThemePath DBus property
  • iconPixmapValue(iconData []byte) []PX — returns empty []PX{} when no
    icon data (allows DE to fall back to IconName); returns normal pixmap
    otherwise
  • createPropSpec: IconName and IconThemePath now initialized from
    package-level vars and marked Writable: true

Backward compatibility

Fully backward compatible. Default values of iconName and iconThemePath
are "" — existing behavior unchanged. iconPixmapValue only returns empty
array when iconData is nil/empty.

Environment

  • OS: Ubuntu 24.04 LTS (Noble)
  • Desktop: MATE 1.26.1 (mate-session-manager 1.26.1-2build2)
  • Tray host: mate-indicator-applet 1.26.0-1build3 via Ayatana indicators
  • Indicator stack:
    • libayatana-appindicator3-1 0.5.93-1build3
    • libayatana-indicator3-7 0.9.4-1build1
    • libdbusmenu-gtk3-4 18.10.20180917~bzr492+repack1-3.1ubuntu5
  • SNI watcher: org.kde.StatusNotifierWatcher (ayatana-indicator process)

Diagnostics

Other apps on the same system (e.g. blueman-tray) correctly use IconName
without IconPixmap:

$ busctl --user get-property org.blueman.Tray /org/blueman/sni \
    org.kde.StatusNotifierItem IconName
s "blueman-active"

Our app before this patch (systray sets only IconPixmap, IconName = ""):

$ busctl --user get-property org.kde.StatusNotifierItem-{PID}-1 \
    /StatusNotifierItem org.kde.StatusNotifierItem IconName
s ""

$ busctl --user get-property org.kde.StatusNotifierItem-{PID}-1 \
    /StatusNotifierItem org.kde.StatusNotifierItem IconPixmap
a(iiay) 1 22 22 0 0 0 0 ...   ← present but ignored by MATE/Ayatana → blank icon

After this patch (SetIconName("link") + SetIconThemePath("/path/to/resources")):

$ busctl --user get-property org.kde.StatusNotifierItem-{PID}-1 \
    /StatusNotifierItem org.kde.StatusNotifierItem IconName
s "link"

$ busctl --user get-property org.kde.StatusNotifierItem-{PID}-1 \
    /StatusNotifierItem org.kde.StatusNotifierItem IconPixmap
a(iiay) 0   ← empty, Ayatana falls back to IconName → icon displayed correctly

Testing

Tested on MATE desktop with mate-indicator-applet (SNI via
org.kde.StatusNotifierItem). Icon switches correctly between states on
SetIconName calls, verified via busctl introspect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant