StatusNotifierItem support

[judemille]

The XEmbed tray specification is outdated, and whether we like it or not, most major DEs and applications are switching to StatusNotifierItem, commonly through libappindicator. The menus and icons are transmitted over DBus, and to simplify implementation, we could use libdbusmenu-gtk3, as the dbusmenu spec is quite complex to implement.

[psychon]

we could use libdbusmenu-gtk3

I tried to take a look at it. Ended up with https://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu/trunk.16.10/files/head:/libdbusmenu-gtk and https://gjs-docs.gnome.org/dbusmenu04~0.4_api/ and I still have no idea how this is supposed to work.

[judemille]

taffybar has managed to figure it out, but that is in Haskell. It could still be used as a reference.

[judemille]

vala-panel has also implemented SNI and Global Menu using libdbusmenu

[judemille]

The Vala implementation is likely easier to read for most people. I wonder if we could just plug this widget in instead of reinventing the wheel. The DE-specific parts aren't that huge. It seems to just be telling DEs how to handle its GTK widget.

[Elv13]

I didn't read the code, but GTK3 cannot be plugged into AwesomeWM. GTK3 depends on the window manager and cannot safely be used in the same thread as the window manager.

[judemille]

I thought beautiful had a GTK3 theme, though. Is that just reading values from the GTK3 config?

[actionless]

@juliandemille it's not showing the GTK window, only creating its object in order to read the StyleContext

[judemille]

Ah, I see. That vastly complicates this issue.

[actionless]

@Elv13 i guess with the new Layout system which you working on it should be possible to embed a client (like vala-panel or whatever) just as a normal widget on a wibar?

[AGCaesar]

After Arch upgraded to Electron 8, neither Franz (multi messenger) nur signal Icons are shown in the tray. This is quite a problem for me :/ I think there wont be a quick solution?

[dtzWill]

And latest keybase client release needs this now, as noted in their release notes: https://github.com/keybase/client/releases/tag/v5.3.0 (likely same issue re:new electron but didn't investigate).

Hmm... :(.

[drskalman]

Apparently Electorn 8 doesn't support old tray anymore just StatusNotifier. I have had limited succes with Taffybar: https://github.com/taffybar/taffybar it is far from perfect (including the fact that you need to recompile the whole thing using haskle everytime you change the config) but it can take over the tray from Awesome and because it support StatusNotifier, at least you won't lose all your Electorn apps when you close the window in the void.

[psychon]

Assuming I did not make a wrong turn somewhere: taffybar uses this library for StatusNotifierItem support: https://hackage.haskell.org/package/status-notifier-item
Looking at its code... I still cannot read haskell.

[judemille]

This was actually one of the libraries I mentioned as a reference in the beginning. The issue seems to be that we're not allowed to use GTK in the main thread, so we need to figure out how to implement this outside of the main thread but still keep it on the bar. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

…

On Monday, March 23, 2020 7:22 AM, Uli Schlachter ***@***.***> wrote: Assuming I did not make a wrong turn somewhere: taffybar uses this library for StatusNotifierItem support: https://hackage.haskell.org/package/status-notifier-item Looking at its code... I still cannot read haskell. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.[https://github.com/notifications/beacon/AB6AFB65FSDRLS4G3YR44GDRI5BALA5CNFSM4KWG4TF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEPU62OY.gif]

[drskalman]

https://git.sr.ht/~steef/snixembed allows you to proxy StatusNotifierItems as XEmbedded systemtray-spec icons. It worked for me riot client icon re-appeared.

[AGCaesar]

Works with signal, but crashes Franz/Ferdi multimessenger. Too bad :/

[psychon]

Uhm. I tried to experiment a bit with this. The Gtk docs say to GNotification instead of GtkStatusIcon. However, GNotification just sends notifications, which we already support?!?
Basically, I rediscovered https://stackoverflow.com/questions/41917903/gtk-3-statusicon-replacement

Also, which spec does snixembed actually implement? It registers itself as org.kde.StatusNotifierWatcher on the bus. There is no mentioning of KDE in the StatusNotifierItem spec (at least none that I can find).

Here is my `GNotification` experiment

local lgi = require("lgi")
local Gtk = lgi.Gtk
local Gio = lgi.Gio

local app = Gtk.Application.new('org.example.app', 0)

function app:on_activate()
	local win = Gtk.Window {
		type = Gtk.WindowType.TOPLEVEL,
		application = app,
		title = "foo",
	}
	win:show_all()
	local notify = Gio.Notification.new("title")
	notify:set_body("this is the body")
	app:send_notification("test-notiy", notify)
	return win
end

app:run{arg[0], ...}

[steef435]

Hello, I am the author of snixembed. It implements necessary parts of this spec, with the exception you noticed that instead of freedesktop, kde is used. IIUC, SNI was originally a KDE project and while testing I discovered plenty software using kde and no software using the standardized naming. I believe the spec is still being used by KDE. Some projects expose both services but I saw no need in practice (and Vala did not make it easy).

There is also the AppIndicator specification (Unity) with similar aims, which seems to be based on SNI but is different and I have not found a specification. snixembed ad hoc reads a bit of it.

Bottom line though, is that it's probably not too important to support either specification for now. I made snixembed because chromium dropped support for traditional (XEmbed) tray icons in favour of only SNI. This is not a big issue for anyone I believe, but the change dripped down to Electron and then it became a problem. Electron has however reverted the change recently. So all apps mentioned in this thread should work just fine on awesome again (for now?).

libappindicator has a fallback to XEmbed tray icons if no watcher service is found, and so does e.g. the QSystemTrayIcon. Since Electron came back, I haven't felt or heard of the need to use snixembed.

The specifications are important for Wayland window managers, since obviously XEmbed doesn't work there. I believe sway has a clean implementation which can be used as a reference in case you want to go ahead with implementing it. It should become widespread at some point, but I think the question is still a bit: which one of the two? (But if you do end up implementing SNI, feel free to shoot if something is weird, I've encountered some weirdness along the way)

[psychon]

@steef435 Thanks a lot for this information. Since I am not sure how I would test my implementation (and yesterday ate up my motivation to work on this), I am not going to work on this any time soon.

Bottom line though, is that it's probably not too important to support either specification for now.

Yay 🎉

[HIDE-r]

https://git.sr.ht/~steef/snixembed allows you to proxy StatusNotifierItems as XEmbedded systemtray-spec icons. It worked for me riot client icon re-appeared.

When I run the snixembed, I found that Electron software's icon is bigger than original icon, and some icon also have transparency. That look so ugly, so have any method can reslove it? If anyone can help, will be very grateful !!!

Before snixembed:

After snixembed:

I run the iwgtk -i, so you can see the wifi logo when after run snixembed.

---

Before snixembed:
The keyboard icon is white.

After snixembed:
The keyboard icon is transparency

[actionless]

@HideOnLie how the icons look when using different panel with systray, not AwesomeWM's?

[HIDE-r]

@HideOnLie how the icons look when using different panel with systray, not AwesomeWM's?

I had try the stalonetray. It also have the same problem.

1. run stalonetray:
   

2. run snixembed:
   

icon will become more bigger, and some icon's theme had change.

[actionless]

It also have the same problem.

then obviously the problem is on the side of icon or icon-rendering routine of those apps, not AwesomeWM