Rofi: Show Xembed tray icons in rofi show window

[edn9]

It this possible? I would love to open some programs who are in my i3bar using rofi.
Example: http://i.imgur.com/bJCo7f1.png

Version

Version: 1.5.1-dirty (tags/1.5.1)

Launch Command

bindsym $alt+Tab exec rofi -show window -lines 6

[DaveDavenport]

I have no idea if that is possible. The tray icons are embedded xwindows¹ (I think) ? and the window is maintained by the application. So you can only have one program showing them.

1. https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html

[edn9]

@DaveDavenport aww thats okay, what im actually doing to "solve" this is using the

bindsym $mod+d exec --no-startup-id rofi -show run -lines 6

to run and open some programs in tray icon, would be really cool tho, thanks!

[sardemff7]

I think it is somehow possible to know the list of icons, but I am not sure there are windows associated with them. These icons are windows on their own, and programs directly handle events in them.
At best, we could emulate a mouse click on them, but not all programs will bring the click the same way, which is terrible UX, so I’d vote against it.

If everyone used the KDE D-Bus interface, maybe, we could have a nicer API to use. Though it could require our own tray, implementing that D-Bus interface, and proxying info to rofi. I don’t know if we can introspect the icons directly without proxying…

[edn9]

Well, If I have them open in another workspace, they will show up for me to click and go, but I wanted to rofi alread input those tray icons to me not to make them always open, you know?

[sardemff7]

We understood your use case, but it cannot be supported.

The tray is not a tasklist/taskbar created by the WM/bar/whatever, it is a complex component where applications can embed an X11 window in. IOW, it is not a “list of windows that can be hidden”.
This means the icon you see in it is not an icon, but a full X11 window (not as full as a toplevel window, but still), independent of any other window.
From a quick reading of the spec and a test on Teamspeak (which uses Qt), there is no property to link the tray icon/window to any application window.

The situation is different under Windows, because there, the tray icon is an icon, with an (optional?) window handle linked to it.
The situation is different under Wayland, because there is no tray, at least for now, and we’d make sure to have whatever is needed if we ever add one. (We probably won’t, because there is already a KDE D-Bus protocol that could work perfectly for that, though I’m not sure the WindowId thing would work OOTB.)
The situation is different under Mac OS because I’m sure they designed their API better.
The situation is different under KDE (if you use mostly KDE stuff) because we could hack our way to proxy their StatusNotifier protocol.
The situation is different under GNOME (if you use mostly GNOME stuff) because we could hack our way to proxy their extension icons.
The situation is different under Enlightenment (if you use mostly E stuff) or at least I believe we could hack our way.
But under plain X11, Xembed is all we have.

[IvanMalison]

But under plain X11, Xembed is all we have.

@sardemff7
That's not really strictly true. I wrote https://github.com/taffybar/gtk-sni-tray about a year ago, which is a standalone tray that supports all versions of the StatusNotifierItem protocol. You can also use that code through taffybar itself. I believe that someone was working on something similar for polybar, but it hasnt quite seen the light of day yet.

@necronoise Would be pretty easy to write a rofi script that does what you want using the relevant dbus protocol, with the caveat that it might be a bit harder to decide which icons actually have associated windows.

[sardemff7]

So basically you are saying you are hacking your way with the KDE/Freedesktop.org protocol.
The original report is about i3bar, which doesn’t support that protocol, and I still believe many X11 clients use Xembed and not a D-Bus protocol, because “D-Bus is for heavy DEs and we don’t want that”. (Which I disagree with, but a lot of people do think that anyway.)

If you want to implement that D-Bus protocol in rofi, please make a PR, or at least track it in a separate issue, because this issue is about “tray icons” in general, which I will rename to Xembed to make things clear.
You may refer to this issue in your PR/issue to explain it covers part of it.

FWIW, I think rofi window mode should only care about StatusNotifierItems with a WindowId, because it’s a mode about windows. Another mode is always possible for the full spec, even with a submenu.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.