XEmbed tray icons not working as expected when running in hyprland

[jannickj]

Hi,

On Hyprland + Waybar, tray icons from Wine/XWayland apps (example: Battle.net via Lutris) do not appear in the Waybar tray by default.

Instead, a small separate tray icon bar is rendered:

Fix / Workaround

1) Install plasma-workspace

This is currently required in order to get xembedsniproxy.

2) Start xembedsniproxy

Adding this to hyprland.conf makes Wine tray icons appear in Waybar:

exec-once = xembedsniproxy

After this, the Battle.net tray icon appears as expected:

3) Hide the blank “black box” window (old tray bar helper)

After enabling xembedsniproxy, Hyprland/XWayland still creates a small blank helper window (the “old tray bar”).
This window commonly has an empty title and can appear as a dark/blurred rectangle.

This rule hides it:

# Hide XWayland helper windows that have an empty title (common for Wine tray/menu helpers)
windowrule = match:xwayland true, match:title ^$, match:class ^$, match:initial_class ^$, match:initial_title ^$, opacity 0.0, float true, no_blur on

no_blur on is required, otherwise the window can remain visible as a faint blurred/dark rectangle even with opacity set to 0.

Note: The windowrule workaround hides an XWayland helper window with an empty title/class, which works here but may be overly broad. It could accidentally affect other legitimate XWayland windows that also appear with empty titles/classes.

After this, the tray icon and menu work as expected:

---

Request / Proposal

Could Hyprland provide a more out-of-the-box solution for Wine/XWayland legacy tray icons, so users don’t have to manually discover and apply workarounds?

Ideally, Hyprland’s XWayland integration would handle legacy XEmbed tray icons in a way that makes them “just work” in common Wayland tray setups (e.g. Waybar), without requiring users to manually start xembedsniproxy and add window rules to hide Wine helper windows.

[corigne]

This would be great. This is really an issue at the wine level, as Wine has no StatusNotifier tray implementation. The only person who has attempted is so far submitted a PR years ago which stalled when the reviewers suggested a refactoring of the entire implementation. Wine is massive, and moves slowly even with critical items, and this doesn't really appear to be a priority for them at the moment.

In the meantime, out-of-the-box solution for Hyprland pattered after or utilizing an existing proxy as a baseline would be a massive improvement for wine-heavy users. Hopefully as the wayland driver for wine matures we will get a native implementation, but I wouldn't hold my breath for it.

[corigne]

This rule hides it:

# Hide XWayland helper windows that have an empty title (common for Wine tray/menu helpers)
windowrule = match:xwayland true, match:title ^$, match:class ^$, match:initial_class ^$, match:initial_title ^$, opacity 0.0, float true, no_blur on`

I have implemented this rule, and it works mostly as expected with waybar, but I'm running into some odd behavior with the helper window being shoved into the top-left corner of the window. I have no rules set which would set windows to 0,0, so the tray dropdowns end up being in the wrong place, partially hidden under my waybar.

This rule works, but xembedsniproxy doesn't seem to work with hyprpanel's tray correctly. The XWayland helper window is still there, and shoved into the top-left of the workspace as before, but click events to the proxy tray icon don't appear to register. This could be due to differences in the sni librarys between the two, I think?

[jannickj]

This would be great. This is really an issue at the wine level, as Wine has no StatusNotifier tray implementation. The only person who has attempted is so far submitted a PR years ago which stalled when the reviewers suggested a refactoring of the entire implementation. Wine is massive, and moves slowly even with critical items, and this doesn't really appear to be a priority for them at the moment.

I think getting a fully supported solution from wine would be the best and that would probably happen eventually, however in the meanwhile hyprland could provide a "good-enough" solution which is just an improved version of my workaround.

I have implemented this rule, and it works mostly as expected with waybar, but I'm running into some odd behavior with the helper window being shoved into the top-left corner of the window. I have no rules set which would set windows to 0,0, so the tray dropdowns end up being in the wrong place, partially hidden under my waybar.

That sounds very strange, for me it works flawlessly with click events firing correctly.

[corigne]

I think getting a fully supported solution from wine would be the best and that would probably happen eventually, however in the meanwhile Hyprland could provide a "good-enough" solution which is just an improved version of my workaround.

I agree with this statement entirely; well put.

That sounds very strange, for me it works flawlessly with click events firing correctly.

I would happily continue to troubleshoot if I had more domain knowledge specific to Hyprland windowing, but the scope of my understanding is the documentation of the configuration including windowing rules and the use of cli tools such as hyprprop to introspect window properties.

If you, or anyone else reading, this can suggest some next-steps to isolating the inconsistency in the helper window behavior I am open to help.

[corigne]

Weirdly, after an update and another few reboots, somewhere along the line the helper window issue resolved itself and now works as expected. Thank you again for your time and help with providing your rule! By the way, you shouldn't need the float rule for this to work.

[Knottentott]

Hi. I was searching around for a solution to this. I am on Hyprland / cachyOS and use Waybar.

Have anyone migrated this solution to Lua config/window rules? I have tried without success to make it work, so if anyone has anything to share, it would be highly appreciated =)

Edit: Not needed. I thought to reboot and see what happened without editing the config. It seems that it works without window rules for me.

[DDoSolitary]

FWIW, starting from KDE 6.7.0 xembedsniproxy sets class of the helper window to xembedsniproxy. This will unfortunately break the "all empty" matching rule, but allows a much cleaner rule directly matching the class.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/6401

[jannickj]

wow I just updated my system today and noticed the blackbox I was quite confused until i saw the window was called xembedsniproxy I thought to myself wow they finally fixed it. I can't believe it was my own post that triggered the change, the linux community is truly something great 😎

Amazing job Qiancheng Sun! 🎉