Open Mikilio opened 1 year ago
I do have the same issue with the nextcloud-client
whenever I launch waybar. Thanks for the workaround @Mikilio and it would be great if this is corrected in waybar
This is an extremely annoying issue. We need some way to check that the tray is initialized and ready to use.
There seems to be a reliable workaround:
systemd.user.services.hyprland-tray-init-shim = {
Unit = {
Description = "hyprland-tray-init-shim";
StopWhenUnneeded = true;
ConditionEnvironment = "WAYLAND_DISPLAY";
Requires = [ "waybar.service" ];
After = [ "waybar.service" ];
};
Service = {
ExecStart =
"${pkgs.bash}/bin/bash -c 'while ! dbus-send --session --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames | grep org.kde.StatusNotifierWatcher; do sleep 0.1; done'";
RemainAfterExit = true;
Type = "oneshot";
Environment = [ "PATH=/run/current-system/sw/bin" ];
};
Install.WantedBy = [ "hyprland-session.target" ];
};
This systemd unit waits until waybar tray is ready (by checking that a dbus service is advertised) then exits. This check seems be more reliable than sleeps.
This systemd unit waits until waybar tray is ready ... then exits.
Having my systemd user services launch after this service does work for me, but causes up to a 15 second delay before waybar appears and my tray apps start. Edit: Waybar doesn't actually have a long delay before advertising StatusNotifierWatcher : tested by running the above bash snippet and cold starting waybar, and the bash job exits almost immediately. However, when sway is first started, waybar is waiting for something before finishing startup. Even when manually launched from a CLI during that 15 second period after sway starts, it just emits [info] Using configuration file ...
and hangs. Based on the output of systemctl --user list-jobs
I suspect it's the XDG desktop portal:
42 graphical-session.target start waiting
83 xdg-desktop-portal.service start running
138 xdg-desktop-portal-wlr.service start waiting
61 nextcloud-client.service start waiting
41 sway-session.target start waiting
While this unfortunately makes the workaround less usable for me, I think this is an issue with my (home-manager's) systemd setup, not with waybar itself. In general, if programs have previously connected to the system bus to provide tray icons, and the StatusNotifierHost is stopped and started later, the tray icons will persist (waybar will pick them up). But here, programs decide on launch that no tray is available and therefore won't connect to dbus to provide them for the rest of their lifespan.
Regardless, even after I patched waybar to support dbus activation, I observed the following : when waybar was not running and I restarted nextcloud-client, waybar was started (so the dbus service file was in effect) but nextcloud-client still didn't show any tray icon. I'm not sure why this occurs : I would have thought that the dbus server would "wai[t] for the application to finish launching and then (if all goes well) delive[r] the message" to set up a tray icon, as described in the KDE docs.
```
From 0e27aa8b6159cba5af5f480697e92bc6d50485fc Mon Sep 17 00:00:00 2001
From: Genevieve
(It's also probably worth linking to https://github.com/Alexays/Waybar/issues/2221 and noting the work to codify a replacement XDG spec, since StatusNotifierItem is old and not well loved, but it doesn't appear to me that work will be finished for a while.)
Originally posted by @alebastr in https://github.com/Alexays/Waybar/issues/483#issuecomment-542528145
Ideally this should be added to the project.