StatusNotifierItem support

judemille commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

judemille commented 4 years ago

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

judemille commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

actionless commented 4 years ago

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

judemille commented 4 years ago

Ah, I see. That vastly complicates this issue.

actionless commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 notifications@github.com 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 commented 4 years ago

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 commented 4 years ago

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

psychon commented 3 years ago

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

```lua 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 commented 3 years ago

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 commented 3 years ago

@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 :tada:

HIDE-r commented 1 year ago

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: