[BUG] Systray widget doesn't draw tray icon of xfce4-power-manager

[shouya]

Checklist before submitting an issue

• I have searched through the existing closed and open issues for eww and made sure this is not a duplicate
• I have specifically verified that this bug is not a common user error
• I am providing as much relevant information as I am able to in this bug report (Minimal config to reproduce the issue for example, if applicable)

Description of the bug

I noticed that some tray icons are not displayed with eww's systray widget. One instance is the tray icon of xfce's power manager. I report it as a bug of eww because stalonetray can pick up the tray icon as expected.

Reproducing the issue

1. Launch eww with the following systray widget:

     (systray
      :class "tray"
      :icon-size 20
      :space-evenly false
      :spacing 2)

2. Launch xfce4-power-manager, make sure "System tray icon" is toggled on from xfce4-power-manager-settings.

3. Notice the tray icon for xfce4-power-manager doesn't show up.

4. Launch stalonetray. Notice the tray icon is shown on the stalonetray as expected.

Expected behaviour

The icon should show in the systray widget.

Additional context

• OS: Debian GNU/Linux trixie/sid
• eww version: eww 0.6.0 73e31e34853a3ba158e3ddc0b28072a1836703dd

[w-lfchen]

1. the commit you're referring to does not exist
2. does setting prepend-new to true fix this?

[shouya]

the commit you're referring to does not exist

Oh i just realized i was using a modified build. but it shouldn't matter because i didn't change anything related to the systray widget.

does setting prepend-new to true fix this?

I just tried that and I see no difference.

[w-lfchen]

i recommend you update your build first, since it's 41 commits behind master

also, if i may ask: why are you removing the magic var? if you don't poll it it shouldn't matter whatsoever, this not being the case would be another bug

also, if possible, can you test whether networkmanagerapplet works as expected?
starting it from a terminal made the icon appear, terminating it made it disappear as expected from my testing

[shouya]

I synced my fork to the latest master. However, it seems that systray is completely broken now. I see no tray icon whatsoever with this version.

why are you removing the magic var?

it was because i have a nfs mount which is not always available on the first few seconds due to network setup delay. in that case, sysinfo::Disks::new_with_refreshed_list would block my status bar from showing up. and if the network condition isn't very stable it may block indefinitely. i don't use EWW_DISK anyway so i edited it out.

can you test whether networkmanagerapplet works as expected?

I can confirm that nm-applet works perfectly in the old build.

[w-lfchen]

regarding your network mounts: that's weird, i don't think that's supposed to be the case since i assumed that command should only run when the var is actually used.

regarding the tray:
this is probably related to #1170, i'll look into reverting the zbus update, seems like i messed up there :(
there probably is some dbus protocol that we don't fully support currently, i've read into this a bit in hopes of fixing this issue eventually, but i currently don't have the time required for this.

before i fully attempt to revert the update:

• can you check whether the old build breaks at 71ba502, specifically?
  (-> is the tray not fully broken on eda9d1e?)
• is there anything in the logs?

[shouya]

I bisected the recent commits and found 71ba502 is the first bad commit.

The only thing interesting in the error log is:

2024-08-30T08:24:28.835Z ERROR eww::widgets::systray  > could not initialise dbus connection for tray: org.freedesktop.DBus.Error.UnknownObject: Unknown object '/org/freedesktop/StatusNotifierWatcher'

[w-lfchen]

managed to reproduce it, will investigate #1170 now; after that, i might be able to look into your specific issue.
thank you for your assistance and my apologies for this mess

[shouya]

thank you for looking into this! i'm happy to help if needed :)

[w-lfchen]

@shouya i've opened #1181, i'd appreciate some testing :3
everything looks good to me, but maybe i'm missing something.
note that your power manager is a different issue for now (sorry)

[shouya]

No problem. I built and tested #1181 and can confirm it fixes the issue introduced in 71ba502.

[w-lfchen]

can you comment that on the pr as well?

i assume your original problem persists, right?

[shouya]

commented.

i assume your original problem persists, right?

yup.

[w-lfchen]

that's unfortunate.
i might look into this at a later point in time, but i currently need to focus on different, personal things, my apologies.
regardless, thank you very much for your assistance on #1181!

[w-lfchen]

bumping this issue since #1202 might be related in some way, the output of the busctl commands might prove helpful in debugging this

[w-lfchen]

according to #1188 (comment), #1203 should fix this issue.
please test this, i am too exhausted rn
sorry

[shouya]

i tried #1203 but unfortunately the issue wasn't fixed on the branch.

the output of the busctl commands might prove helpful in debugging this

could you show me what how to collect the information needed? i'm not familiar with dbus nor xdg notifier protocol.

[w-lfchen]

sure, can you give me the output of
$ busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher?

the first goal is to determine the dbus objects that the power manager announces
i can't really test this on my machine sadly as the application refuses to start in any way for me sadly :/

also, two more things:

• i'm guessing that the logs don't show anything?
• are you able to try whether the application works fine with stray?

[shouya]

here's the output:

$ busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 5 ":1.10037/StatusNotifierItem" ":1.5060/org/ayatana/NotificationItem/nm_applet" ":1.5045/org/ayatana/NotificationItem/pasystray" ":1.5111/StatusNotifierItem" ":1.10488/StatusNotifierItem"

$ busctl --user tree :1.10037
├─ /MenuBar
└─ /StatusNotifierItem

$ busctl --user tree :1.5060
└─ /org
  ├─ /org/ayatana
  │ └─ /org/ayatana/NotificationItem
  │   └─ /org/ayatana/NotificationItem/nm_applet
  │     └─ /org/ayatana/NotificationItem/nm_applet/Menu
  └─ /org/freedesktop
    └─ /org/freedesktop/network_manager_applet

$ busctl --user tree :1.5045
└─ /org
  └─ /org/ayatana
    └─ /org/ayatana/NotificationItem
      └─ /org/ayatana/NotificationItem/pasystray
        └─ /org/ayatana/NotificationItem/pasystray/Menu

$ busctl --user tree :1.5111
├─ /MenuBar
└─ /StatusNotifierItem

$ busctl --user tree :1.10488
├─ /MenuBar
└─ /StatusNotifierItem

i'm guessing that the logs don't show anything?

right. the eww log doesn't show any relevant.

are you able to try whether the application works fine with stray?

sure. i can't do it now but i will test it out tomorrow and let you know.

[shouya]

are you able to try whether the application works fine with stray?

I tried stray but it doesn't show the icon of xfce4-power-manager.

[MonaMayrhofer]

I think it would also be interesting to know which of the applications (probably one that follow the non-ayatana format, so one where the objects are /MenuBar and /StatusNotifierItem) actually is xfce4-power-manager.

busctl --user list lists all processes currently present on the session dbus. The output should look something like

NAME                                          PID PROCESS         USER    CONNECTION    UNIT              SESSION DESCRIPTION
:1.0                                         2167 systemd         nionidh :1.0          [email protected] -       -          
:1.1                                         2185 gdm-wayland-ses nionidh :1.1          session-2.scope   2       -          
:1.10                                        2333 .xdg-permission nionidh :1.10         [email protected] -       -

There you can look for the the NAME of the service that is launched by the xfce4-power-manager (as seen in the PROCESS column).

Then double check if a service with that NAME is present in the output of
busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher to see if xfce4-power-manager is actually registering with the StatusNotifierWatcher.

Note that the service names depend on the order in which they are started within the session, so they are unstable and can change between (service) restarts.

Then once you know which service NAME belongs to the xfce4-power-manager through the first command, you can again run the
busctl --user tree NAME
to list all the objects within that service (as you have done above already)

Then once you know all the objects within the service you can introspect all the individual objects using
busctl --user introspect NAME OBJECT_PATH, so something like busctl --user introspect :1.12 /StatusNotifierItem

[shouya]

Thank you, here's the relevant output:

$ busctl --user list | grep xfce
:1.11320                                     2516800 xfce4-screensav shou :1.11320      session-1888.scope 1888    -
:1.11321                                     2516800 xfce4-screensav shou :1.11321      session-1888.scope 1888    -
:1.11435                                     2549593 xfce4-power-man shou :1.11435      session-1888.scope 1888    -
:1.11436                                     2549593 xfce4-power-man shou :1.11436      session-1888.scope 1888    -
org.freedesktop.PowerManagement              2549593 xfce4-power-man shou :1.11435      session-1888.scope 1888    -
org.xfce.FileManager                               - -               -    (activatable) -                  -       -
org.xfce.PowerManager                        2549593 xfce4-power-man shou :1.11435      session-1888.scope 1888    -
org.xfce.ScreenSaver                         2516800 xfce4-screensav shou :1.11321      session-1888.scope 1888    -
org.xfce.Thunar                                    - -               -    (activatable) -                  -       -
org.xfce.Xfconf                              2549602 xfconfd         shou :1.11437      [email protected]  -       -

$ busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 5 ":1.11337/StatusNotifierItem" ":1.11329/org/ayatana/NotificationItem/nm_applet" ":1.11354/StatusNotifierItem" ":1.11314/org/ayatana/NotificationItem/pasystray" ":1.11365/StatusNotifierItem"

So there is no services by xfce4-pm registered as status notifier items. However, stalonetray can display its tray icon without an issue. It appears that xfce4-pm doesn't use org.kde.StatusNotifierWatcher for registering tray icon?

---

I grepped the source of xfpm and found the relevant code for showing tray icon. From my limited research it looks like XEmbed protocol (correct me if i'm wrong).

Searching with keyword "xembed" i saw some discussions about the topic when systray was introduced: #111. Apparently XEmbed protocol is not supported. Is there any hope to see this legacy protocol implement on eww?

[w-lfchen]

sorry for taking so long to get back to this issue, i was occupied by my personal life.

#111 (comment) mentions that the protocol is legacy and shouldn't really be used anyways.
i guess that this is also why stray doesn't support it either; implementing it would probably be difficult since not even all compositors implement it.

#111 (comment) mentions a workaround, are you able to try it out?

[shouya]

I tried xembed-sni-proxy but the result is not satisfactory. The icon indeed shows up on eww systray, but the icon image shown is just the fallback icon. Interactivity (left click, right click) also doesn't seem to work. So overall a bad result.

That said, although I'd like to see XEmbed supported from a user's perspective, I fully understand the complexity it may add for little gain. For this case, I'm actually perfectly fine without the tray icon for xfce4-power-manager. Thanks a lot for your support this far, I appreciate it :)

[w-lfchen]

thank you for your understanding. feel free to open a feature request for the protocol, though i doubt it will be really addressed sadly :/