Closed MonaMayrhofer closed 2 months ago
MonaMayrhofer
commented
2 months ago It seems like the service string for nm-applet is :1.81 which is shorter than the 6 characters, expected by
I do not know the specifics of dbus / sni, but something about the service just being a few numbers just feels off, isn't it supposed to have a suffix, like described in the comment above the fn in question?
w-lfchen
commented
2 months ago that's weird, i can't seem to reproduce this. which nixpkgs commit are you on?
MonaMayrhofer
commented
2 months ago It looks like nm-applet is not providing any of the kde StatusNotifierItem dbus entries, but instead providing the ones from ayatana https://ayatanaindicators.github.io/
-> busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 1 ":1.89"
-> busctl --user tree :1.89
└─ /org
├─ /org/ayatana
│ └─ /org/ayatana/NotificationItem
│ └─ /org/ayatana/NotificationItem/nm_applet
│ └─ /org/ayatana/NotificationItem/nm_applet/Menu
└─ /org/freedesktop
└─ /org/freedesktop/network_manager_appletSame thing for udiskie
busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 1 ":1.108"
busctl --user tree :1.108
└─ /org
└─ /org/ayatana
└─ /org/ayatana/NotificationItem
└─ /org/ayatana/NotificationItem/udiskie
└─ /org/ayatana/NotificationItem/udiskie/MenuIm on:
"nixpkgs": {
"locked": {
"lastModified": 1722221733,
"owner": "NixOS",
"repo": "nixpkgs",
"rev": "12bf09802d77264e441f48e25459c10c93eada2e",
"type": "github"
},
"original": {
"id": "nixpkgs",
"ref": "nixos-24.05",
"type": "indirect"
}
},
Oh wait, i seem to have mixed things up... udiskie does provide the org.kde.StatusNotifierItem interface - its just under a different path than what eww seems to expect.
-> busctl --user introspect :1.108 /org/ayatana/NotificationItem/udiskie
NAME TYPE SIGNATURE RESULT/VALUE FLAGS
org.freedesktop.DBus.Introspectable interface - - -
.Introspect method - s -
org.freedesktop.DBus.Peer interface - - -
.GetMachineId method - s -
.Ping method - - -
org.freedesktop.DBus.Properties interface - - -
.Get method ss v -
.GetAll method s a{sv} -
.Set method ssv - -
.PropertiesChanged signal sa{sv}as - -
org.kde.StatusNotifierItem interface - - -
.Scroll method is - -
.SecondaryActivate method ii - -
.XAyatanaSecondaryActivate method u - -
.AttentionAccessibleDesc property s "" emits-change
.AttentionIconName property s "" emits-change
.Category property s "Hardware" emits-change
.IconAccessibleDesc property s "" emits-change
.IconName property s "drive-removable-media" emits-change
.IconThemePath property s "" emits-change
.Id property s "udiskie" emits-change
.Menu property o "/org/ayatana/NotificationItem/udiskie/… emits-change
.Status property s "Active" emits-change
.Title property s "udiskie" emits-change
.XAyatanaLabel property s "" emits-change
.XAyatanaLabelGuide property s "" emits-change
.XAyatanaOrderingIndex property u 0 emits-change
.NewAttentionIcon signal - - -
.NewIcon signal - - -
.NewIconThemePath signal s - -
.NewStatus signal s - -
.NewTitle signal - - -
.XAyatanaNewLabel signal ss - -i'm still having issues reproducing this, sorry :/
using nix run github:nixos/nixpkgs/12bf09802d77264e441f48e25459c10c93eada2e#networkmanagerapplet doesn't yield any issues
MonaMayrhofer
commented
2 months ago Running that, does no longer lead to a panic for me (however thats only because the nm-applet service is now :1.123 with 3 digits and no longer something with only 2 digits (But thats only because that number seems to continually increase).
However it still doesn't work:
2024-09-20T08:43:18.392Z WARN eww::widgets::systray > failed to set menu: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/StatusNotifierItem”
2024-09-20T08:43:18.392Z ERROR eww::widgets::systray > error for systray item :1.123: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/StatusNotifierItem”
Listing the objects of :1.123 still shows there's nothing at /StatusNotifierItem, like eww expects.
-> busctl --user tree :1.123
└─ /org
├─ /org/ayatana
│ └─ /org/ayatana/NotificationItem
│ └─ /org/ayatana/NotificationItem/nm_applet
│ └─ /org/ayatana/NotificationItem/nm_applet/Menu
└─ /org/freedesktop
└─ /org/freedesktop/network_manager_appletCan you run busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems?
I am curious if your services are also registered at the weird number or if yours actually have a path like line 62 seems to expect:
w-lfchen
commented
2 months ago $ busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 2 ":1.28/org/ayatana/NotificationItem/spotify_client" ":1.13589/org/ayatana/NotificationItem/nm_applet"Yea, thats the problem, for some reason on my system they aren't registering with the object path, just the service, so i fall into line 64, and yours is in line 62
-> busctl --user get-property org.kde.StatusNotifierWatcher /StatusNotifierWatcher org.kde.StatusNotifierWatcher RegisteredStatusNotifierItems
as 1 ":1.123"that seems more like a dbus issue to me though or am i reading this wrong
are there any objects registered under that destination?
i'm too dumb to read logs my bad
busctl --user tree :1.13589 gives me the same output as yours here
MonaMayrhofer
commented
2 months ago Yup, it definitely is an issue with my dbus setup that nm_applet doesn't register the correct object path into the StatusNotifierWatcher.
However it seems like line 64 is supposed to catch this issue and panics for short service names.
There are no objects registered at /StatusNotifierItem, just the ayatana ones at /org/ayatana/NotifictaionItem/nm_applet, like on your system.
If i change line 64 to temporarily hardcode the correct path, so:
(service[0..(6.min(service.len()))].to_owned(), "/org/ayatana/NotificationItem/nm_applet".into())
it works like a charm....
w-lfchen
commented
2 months ago is the [0..(6.min(service.len()))] even needed? it seems useless to me at this point, i'd try simply removing it
i think what should be evaluated is how stray handles this, as the logic seems to be strongly inspired from there
i currently don't really have the time to work on this myself, but feel free to open a pr, i'll do my best to test and review it if you do! that pr could probably also seek to address #1180, these issues might be related in some way
MonaMayrhofer
commented
2 months ago Its very strange - if i monitor the session dbus traffic with bustle or dbus-monitor --session i can see the Message where nm_applet registers itself
method call time=1726823244.902165 sender=:1.150 -> destination=:1.5 serial=25 path=/StatusNotifierWatcher; interface=org.kde.StatusNotifierWatcher; member=RegisterStatusNotifierItem
string "/org/ayatana/NotificationItem/nm_applet"and there it includes the correct object path.
You are right the [0..(6.min(service.len()))] should probably be replaced with just service - i wonder what the reason for that slicing was in the first place.
Sure I'll look into it more and PR any things that can actually be resolved within eww, and are not just a misconfiguration on my part.
One thing that could be the culprit is that I am using the status-notifier-watcher service from home-manager to provide the org.kde.StatusNotifierWatcher service which uses haskellPackages.status-notifier-item v0.3.1.0
w-lfchen
commented
2 months ago i have not changed anything from the default implementation for status-notifier-watcher, didn't even know there is a hm option for that ^^'
so that might be worth testing
MonaMayrhofer
commented
2 months ago Yes! That was the problem. That has been a remnant of my taffybar times, I did not realise eww comes with its own ord.kde.StatusNotifierWaatcher service.
Now that i know it, it seems quite obvious.
So it was entirely my fault.
I wonder, however, if we should change up line 64 anyways, cause the slicing is definitely broken as it assumes service names that are exactly 6 chars long, and also as far as I understood it, the object will never be at the path that names::ITEM_OBJECT.to_owned() expects...
But tbh the entire branch kinda seems like a band-aid for some specific application that does werid stuff with the dbus, so I am reluctant to really change it up without knowing why it exists.
Maybe we should at least emit a warning that puts people onto the right track...
w-lfchen
commented
2 months ago a warning about falling back to a default attempt to address the object seems reasonable
i think it'd be best to investigate #1180 first tho
MonaMayrhofer
commented
2 months ago Then it's probably best to close this issue, and continue all further investigation over there.
Kage-Yami
commented
2 weeks ago So I've just started exploring this because I was getting the panic on my Ultramarine Linux 40 (i.e. Fedora-based) system, running Budgie Desktop (i.e. X11, in case that makes a difference for this)
Not currently on that exact system, but last night when I was, with:
busctl --user \
get-property org.kde.StatusNotifierWatcher \
/StatusNotifierWatcher \
org.kde.StatusNotifierWatcher \
RegisteredStatusNotifierItems... I was getting two path-less results as described in this thread (one was for nm-applet, the other for Ulauncher); nm-applet had only a 2-digit ID (i.e. 5-length string).
A quick hack later to remove the [0..6] slicing, and both items failed on a later step; don't remember the exact message, but it was something to do with not being able to find the path.
However, running that command on the system I'm currently on (Fedora 40 with KDE, Wayland), I note that there are items that have the "default" /StatusNotifierItem path, some alongside a 2-digit ID and some alongside a non-numerical ID (newlines inserted to reduce horizontal scrolling pain):
as 9
":1.48/StatusNotifierItem"
":1.61/StatusNotifierItem"
":1.63/org/ayatana/NotificationItem/ulauncher"
":1.71/org/ayatana/NotificationItem/tray_id"
":1.75/StatusNotifierItem"
"com.jetbrains.toolbox/StatusNotifierItem"
":1.76/org/ayatana/NotificationItem/9fS_9JCsD7"
":1.96/StatusNotifierItem"
":1.88/org/ayatana/NotificationItem/steam"busctl --user tree for ambiguous items above (not that they're all necessarily any more helpful)...(I've not run Eww on this Fedora 40 KDE system, as my intent with Eww is to be able to have a secondary-monitor taskbar on a Budgie system, which does not natively support such a thing, thus letting me reinstall my Fedora 40 KDE [on a two-monitor system] to match the Ultramarine one [which is only single-monitor, but works for experimentation].)
So it seems, depending on environment, at least all of the following permutations are possible (based on observations in this thread, presumably other permutations are also possible):
:<number>.<number>
:<number>.<number>/StatusNotifierItem
:<number>.<number>/<string-path>
<namespace-string>/StatusNotifierItem
I'm not sure at this stage what status-notifier-watcher or home-manager are all about at this time (not yet explored those), but my main take-away is that the failure case is not just a result of "esoteric" environments, but also a result of (what I can only assume are) pretty stock/ordinary DE installations (e.g. Budgie Desktop).
So that probably warrants re-opening this? (Although the issue as described by the title is only 1 of 2 problems...)
I'm going to be exploring this some more, although this is all very new to me (outside of some raw Rust hobby-experience), so can't say whether I'd be able to come up with any more information or ideas...
Kage-Yami
commented
2 weeks ago So I've been able to resolve the issue with these changes: https://github.com/elkowar/eww/compare/master...Kage-Yami:eww:fix/pathless-systray-items
Basically, it uses DBus interface introspection at a fixed /org/ayatana/NotificationItem path on the "misbehaving" addresses, parses out the resulting XML, and grabs the first child node, assuming that is the correct path for the StatusNotifierItem object we want.
I see a few potential issues (even if only from an "appetite" perspective) with it before it could be merged in (but happy to create a pull request so it can be iterated on):
quick-xml (and makes serde no longer a transient-only dependency)
StatusNotifierItem/org/ayatana/NotificationItem is always the correct parent path to the StatusNotifierItem object
/ looking for objects that implement StatusNotifierItem and take e.g. the first found?quick-xml errors in zbus errors will break when the zbus 4.x -> 5.x can of worms is opened again
zbus 5.x removes ::Error::QuickXml (and the quick-xml feature); could probably use the generic ::Error::Failure instead (even before the version bump)?w-lfchen
commented
2 weeks ago feel free to open a pr! i'll see whether i can help out, but i'm rather busy these days so please don't expect much.
i don't think it's a good idea to rely on outdated features though, so maybe we should look into different ways to solve this issue (ideally migrating to zbus 5.1.1 while doing so)
Kage-Yami
commented
2 weeks ago PR created: https://github.com/elkowar/eww/pull/1230
Ended up taking the time to crawl the tree to find the first org.kde.StatusNotifierItem, instead of just assuming it was directly under /org/ayatana/NotificationItem.
Also scrapped the wrapping of quick-xml errors in xbus::Error::QuickXml, so that should no longer cause us any problems when it comes to zbus upgrade time (which I believe should be done separately, rather than "overload" this change).
Checklist before submitting an issue
Description of the bug
When trying to create a window with the systray widget, eww panics on my system.
Reproducing the issue
Having the config
in
examples/systray/eww.yuck.Then starting a program that provides systray entries like
nm-appletThen running
Additional context
I am driving NixOS and Hyprland. This issue appears on eww main at commit 8661abf2bf07f5a809fc995233d93810cc1ac871, however I assume it would have been around since #743
I will keep investigating this and post updates in here, however if there is any guidace, that would be greatly appreciated as this is my first time within the eww codebase.