Tray icon on Wayland

[Weishaupt]

I'm trying to run udiskie with a tray icon on wayland, but this fails with the following error

$ udiskie -t

(udiskie:19307): Gtk-CRITICAL **: 15:13:21.132: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

My setup

• ArchLinux
• sway
• waybar (with tray support)

[coldfix]

Hi,

I have little experience with wayland, but I will try to check up whether I can reproduce this during the weekend.

Do you have any issues with other applications displaying tray icons?

Is this an actual crash (program terminates) or is it just some message appearing as output?

Best, Thomas

[Weishaupt]

I don't have issues with other tray icons (udiskie is the only GTK-based one though). Apart from the tray udiskie seems to work. At least it isn't crashing, only the warning is produced and no tray icon is displayed.

[coldfix]

I have now tried running sway+waybar, and I could reproduce your problem, but I also had a bad experience apart from that:

• window manager doesn't occupy the full screen (about 1/4th of the screen on the right stays black)
• keyboard layout not working properly (my bad, was starting via startx, not directly)
• exit hotkey (mod+shift+e) shows a prompt, but the "Yes, exit sway" button doesn't work (showing the command failed to run: Failed to execute child process “-e” (No such file or directory) in the terminal), so had to exit using pkill sway
• except for kalu, none of my tray icons show up (either crash when started, or simply don't show), and even kalu fails to show a menu when clicked and shows messages like the following when starting:

 `(kalu:61876): Gtk-CRITICAL **: 11:41:15.254: gtk_status_icon_set_from_icon_name: assertion 'GTK_IS_STATUS_ICON (status_icon)' failed`

It could be related to this comment from the swaywm wiki:

There are two standards for status icons: XEmbed and StatusNotifierItem (SNI). XEmbed is legacy and unimplemented in Sway. SNI is supported by swaybar. If your app uses XEmbed, the status icon won't show up. You should ask them to upgrade to SNI.

udiskie implements tray using GtkStatusIcon as well as AppIndicator3 (using the --appindicator option). Neither shows up. I don't know for either option whether they are based on xembed or sni, or if they can adapt to what's available.

Therefore, I'm sorry that this is a wontfix from my side so far, but if you happen to figure out the problem, I'm happy to accept a pull-request or hints for patching.

Best, Thomas

[robertjk]

I came for the same issue, as I'm getting the same error on sway:

$ udiskie --tray

(udiskie:115048): Gtk-CRITICAL **: 00:04:54.083: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

It could be related to this comment from the swaywm wiki:

There are two standards for status icons: XEmbed and StatusNotifierItem (SNI). XEmbed is legacy and unimplemented in Sway. SNI is supported by swaybar. If your app uses XEmbed, the status icon won't show up. You should ask them to upgrade to SNI.

udiskie implements tray using GtkStatusIcon as well as AppIndicator3 (using the --appindicator option). Neither shows up. I don't know for either option whether they are based on xembed or sni, or if they can adapt to what's available.

libappindicator says it uses KSNI. What is that and how is that different from SNI that swaywm supposedly supports, I don't know.

[soyuka]

Hi, same issue brought me here

udiskie -v  -t --appindicator

Works! Just make sure you have libappindicator-gtk3 installed.

[coldfix]

thanks @soyuka!

After your comment, I realized the --appindicator flag is effective only if also providing --tray. With this the udiskie appindicator icon shows for me too. I will change the behaviour so --appindicator is sufficient.

@Weishaupt @robertjk Can you confirm that this works for you as well?

Best, Thomas

[robertjk]

It doesn't fully work for me. Yes, the icon is displayed:

But when I open the context menu it's totally unreadable:

I installed libappindicator-gtk3 package (Arch) and ran by udiskie --automount --tray --notify --appindicator &. I'm running Sway and Waybar.

[coldfix]

Thanks for the update. I have seen similar issues with the udiskie menu not displaying correctly when using the appindicator within my usual environment. For some reason, it seems to work under sway (but only after clicking two or three times), while another application (kalu) shows the same erroneous behaviour there.

I will leave this open for now and investigate a bit, but I can't promise that I will figure something out.

[robertjk]

I'm running Sway and the above screenshot is from Waybar ran in Sway. Cool, let's leave it open and maybe at some point it'll get fixed. Thanks for help!

[coldfix]

One part of the issue seems to be that a call to menu.show_all() is missing. With the call it shows properly on my machine.

However the situation is still not resolved, because I noticed that the handler which is supposed be called after the user clicks the icon, before the menu is shown, never gets called, and therefore doesn't update the menu.

I also noticed that the following message appears when using appindicator:

Gdk-CRITICAL **: 18:42:33.305: gdk_window_thaw_toplevel_updates: assertion 'window->update_and_descendants_freeze_count > 0' failed

Can't trace this so far.

[coldfix]

Update on my interim findings, mostly for future-me:

For lack of a proper mechanism in the AppIndicator3 AP itself, udiskie.appindicator currently uses the following hack (which I adapted from comment 15 of this bug report back in the day when I added this module) to subscribe to an about-to-show signal:

        dbusmenuserver = self._indicator.get_property('dbus-menu-server')
        self._dbusmenuitem = dbusmenuserver.get_property('root-node')
        self._conn = self._dbusmenuitem.connect('about-to-show', self._on_show)

Today, this signal:

• does not fire when I'm testing in my usual environment (awesome-wm)
• does fire under some ancient ubuntu 14 which I used to test this feature back in the day (I still have the VM and it still works). Under this old ubuntu the menu is displayed correctly with the current code, and updates within the about-to-show handler are effective
• does fire under sway/waybar. The about-to-show handler can successfully change the menu, but this does not update the geometry of the menu, so if new items get appended, the user will not be able to see them, unless they scroll down the menu. If no items set to be shown, prior to displaying the menu the first time, it can happen that the menu is a small box with no visible items. This might be a bug in waybar
• I have so far not checked under a recent ubuntu or other distros

Furthermore, via this signal and Indicator.get_property we unfortunately have access only to very restricted versions of Dbusmenuitem objects, which unfortunately do not provide the full API of Dbusmenu.Menuitem (in fact basically only connecting signals) (with the full API one might at least hope to achieve our goals).

IMO, AppIndicator is utterly broken because

• it does not distinguish different actions (left/right mouse)
• there is no reliable way to dynamically update the menu before showing
• there is no reliable way to detect if a compatible tray area exists and the icon actually gets shown or not

So, I searched a bit for alternatives, and found the following:

• AppIndicator3 itself. I think AyatanaAppIndicator3 is a synonym recently? AFAIU this is a dumbed-down adaption by canonical of the KStatusNotifierItem protocol (see below). Very annoying.
• Gtk.StatusIcon of course but doesn't support SNI, otherwise fine
• QSystemTrayIcon supports both SNI and XEmbed and supports all features that I want, but is Qt, so will probably require a lot of work in porting udiskie over
• KStatusNotifierItem. reference implementation? not yet sure how exactly it is different from QSystemTrayIcon
• statusnotifier Library to use KDE's StatusNotifierItem via GObject. Unfortunately, there no python bindings I guess, otherwise might have been the perfect candidate. ....
• StatusNotifier GI API as used here. I have not found this documented anywhere so far, but this may be a GI binding for statusnotifier above. Looks very promising anyway!
• roll a custom DBus implementation of the StatusNotifierItem specification. Lots of work
• XApp.StatusIcon. A recent alternative development by the mint team. The API looks reasonable, but it doesn't support SNI (at least doesn't work with waybar) since they made their own protocol AFAIU.

Long term solution may be to migrate udiskie to Qt where more reliable alternatives are available (QSystemTrayIcon/KStatusNotifierItem) that should work with waybar while supporting all features that are needed. Also, I have some quarrels with gtk3+ regarding menus, ease-of-use, and their history of deprecating useful features

It's not just me, others seem to despise appindicator as well, some references:

• Ditch appindicator and write our own DBus interfaces/proxies
• Provide a D-Bus based StatusNotifierItem instead of a GtkStatusIcon
• The StatusIcon protocol for the XApp is an unnecessary overwork and a divergent project.
• How to design a status icon library in 2019

[robertjk]

Wow, it seems you did quite a research. Respect 🙇‍♂️ .

[mox-mox]

Hi, I just started using udiskie under wayland. Cool project! If you need testing I'd be glad to help :)

[somini]

You can add appindicator: true on the configuration program_options YML to default. The defaults are not updated and the "flat" menu option is ignored, but it's usable at least.

[nicewarmcoffee]

I am having an issue with the tray as well on sway

$ udiskie -t
Not run within X session. 
Starting udiskie without tray icon.

$ cat ~/.config/udiskie/config.yml 
program_options:
    tray: true
    appindicator: true
    file_manager: ranger
    terminal: 'kitty -d'

$ emerge -avp udiskie

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ~] sys-fs/udiskie-2.2.0::gentoo  PYTHON_TARGETS="python3_7 -python3_8" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Tested with both appindicator on and off, same behaviour on both 2.2 and 2.1.
Automount/notifications are working perfectly so I have no complaints.

[ghost]

Hello coldfix,
I am having the same issue as ultratensai, i.e. I get the Not run within X session. Starting udiskie without tray icon. warning/error when running udiskie --appindicator. I was able to get around it by setting the DISPLAY environment variable, but I don’t know if there’s other code that this workaround could break.

Would you please adjust it to work without $DISPLAY? Possibly check for $WAYLAND_DISPLAY as well, or less, or more (e.g. use appindicator by default when under wayland, I don’t know if it’s a good idea).

This line should definitely be changed:

udiskie/udiskie/cli.py

Line 380 in d7b95ae

if show_tray and not _in_X:

[coldfix]

Hi @tiosgz,

ok. I agree that something definitely has to change about wayland support. I currently don't have much time. Might have some time next weekend. Otherwise feel free to submit PRs.

Best, Thomas

[coldfix]

FYI, I have added a workaround that should hopefully display the tray menu correctly from now on, at the (minor) cost of moving the device list into a submenu.

[kberkut]

I'm have error message and icon udiskie not present in tray.

`udiskie -t

(udiskie:4248): Gtk-CRITICAL **: 09:26:44.847: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed`

`community/udiskie 2.4.2-1 [установлен]

Removable disk automounter using udisks`

---

OS: Arch Linux x86_64
Host: 81NC Lenovo IdeaPad S340-15API
Kernel: 6.2.7-arch1-1
Uptime: 14 mins
Packages: 1858 (pacman), 14 (flatpak)
Shell: zsh 5.9
Resolution: 1920x1080
DE: GNOME 43.3
WM: Mutter
WM Theme: Adwaita
Theme: Adwaita [GTK2/3]
Icons: Faenza [GTK2/3]
Terminal: qterminal
Terminal Font: DejaVu Sans Mono 12
CPU: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8) @ 2.100GHz
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series
Memory: 2879MiB / 9886MiB