Adopt the StatusNotifierItem specification

[Airblader]

The XEmbed based system tray specification is horrible. We've noticed this when trying to allow transparency, and so has awesome.

Even all the big players, namely Unity, KDE and Gnome, started deprecating the tray specification and seem to be betting on the replacement instead: the StatusNotifierItem specification.

I haven't looked at the spec yet, but we should consider starting to implement this as well.

References
[1] http://blog.martin-graesslin.com/blog/2014/03/system-tray-in-plasma-next/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=734826
[3] https://mail.gnome.org/archives/gnome-flashback-list/2015-April/msg00009.html

[stapelberg]

Thanks for bringing this up, I think implementing this sounds reasonable in theory.

Given that the StatusNotifierItem spec seems to be based on dbus, we’ll need to have a careful look at which dbus libraries are out there that we can depend on.

[Airblader]

Alright. I'm not going to work on this right away, too much on my plate already, but I'll mark it as accepted for now under the usual restrictions and disclaimers.

[Airblader]

@stapelberg We already depend on glib (if compiled with pango, anyway) which comes with a dbus API, so I think we should just use that one.

[stapelberg]

I haven’t used that API, but the fact that we already depend on glib is a strong plus of course. I guess we should try using the glib dbus API.

[psychon]

GDbus is actually part of Gio and not GLib (but the two are clearly related).

[orestisfl]

dbus-glib is a deprecated API for use of D-Bus from GLib applications. Do not use it in new code.
Since version 2.26, GLib's accompanying GIO library provides a high-level API for D-Bus, "GDBus", based on an independent reimplementation of the D-Bus protocol. The maintainers of D-Bus recommend that GLib applications should use GDBus instead of dbus-glib.

Some implementations:

• sway (MIT): low-level dbus library + cairo. Implement Tray Icons swaywm/sway#1234 for SNI, Support libappindicator swaywm/sway#1431 for appindicator (0.15 tree).
• xfce4-statusnotifier-plugin (GPL) / homepage: GIO + GTK.
• gnome-shell-extension-appindicator (GPL) / homepage: GIO + GTK, javascript
• cinnamon (GPL): GIO + GTK, javascript
• lxqt-panel (LGPL): QT
• xfce4-sntray-plugin (LGPL): Vala, GTK, Glib
• core/enlightenment (BSD-3): Enlightenment stuff
• KDE Plasma Workspace (LGPL): QT

[reitzig]

Got here after searching for issues related to the problem I'm seeing with transparent icons:

This keeps popping up: #2325, #2447, #3197 -- it is an awful user experience, and one we users can't do anything about. ("Please, commercial product, don't use transparency in your icon." -- not going to work.)

Is there any timeline on this issue, or should we open one to handle transparent icons in some way? (Just draw a square of background color behind each icon...)

[psychon]

@reitzig You are only seeing this with Qt-using applications, right? If so, I have good news for you: I remember seeing some patch that fixes this in Qt. A quick search found: https://codereview.qt-project.org/#/c/139051/ (which seems to be stalled, sigh).

[reitzig]

@psychon I don't have enough data to say so. The one app I notice this with is a Qt one, yes. Most other apps don't have a lot of transparency in their icons, though.

[mxmilkiib]

Hexchat is gtk2, second icon is Kmix, third is Cadence (blue nuclear icon), both qt5. Fourth is redshift, fifth caffeine-ng and sixth radiotray-ng, which are all gtk3.

Would a StatusNotifierItem/AppIndicator tray would lose the difference between a left/right mouse click on an icon, as well as icon hover tooltips? Or am I getting my wires crossed?

[GordianDziwis]

Bumping this, got the missing redraw with qt icons and the background of gtk3 icons is transparent.

Depending on the open window (bar is set to autohide), the icons are not recognizable. It is not just an aesthetic problem.

[Airblader]

Please do not bump issues if you're not adding any new information. You can use the reactions on the issue to voice support or get started contributing yourself. Bump comments just cause unnecessary notifications for all subscribed users. Thanks!

[heroin-moose]

@Airblader, is this something you are considering to implement?

[Airblader]

Personally, no.

[Gigadoc2]

Maybe a bit off-topic, but since GNOME has dropped status items as a whole quite some time ago, I don't think this will ever get implemented.
Some of the reasons they named also apply to tiling wm users. In particular, you can't really control which icons you get (not every application lets you disable tray icons), and you can't control the order of these icons either.

Personally, I battled with the xembed problems as well for years, even went so far as to switch to sway + waybar primarily for the SNI icons, but even there they aren't all that nice.
I have finally settled with just keeping the windows of applications that would have status icons open on specific workspaces, turning off status icons entirely. So far, I have not encountered any application that really need status icons.

[crocket]

@Gigadoc2 What about redshift-gtk, ibus, fcitx, and parcellite? I don't yet know an alternative to status icon for displaying status or presence for those applications.

[heroin-moose]

FYI, I cannot reproduce this on polybar. If anyone is still struggling with this consider a move.

[Gigadoc2]

@Gigadoc2 What about redshift-gtk, ibus, fcitx, and parcellite? I don't yet know an alternative to status icon for displaying status or presence for those applications.

Personally, I just run redshift without any ui frontend, it works fine in the background. I've never used an input method, so I am not sure about those, but don't you usually activate them with a shortcut anyway? If so, you do you really need the icons still? For clipboard managers, I think there are some that can be used with just shortcuts as well (I found clipmenu with a quick search). Personally I don't use them at all anymore, due to security concerns (and wayland).

I mean, this is just personal preference and you may very validly have a different preference. I just wanted to encourage all those who were like past me to just try and live without status icons for a few weeks, and see if you still miss them.

It also depends on what you use the status icons for. If you use them for interacting with applications, I'd ask if that is really a convenient way to use applications, considering that the tray icons change order all the time? For tiling WMs setting up keybindings for apps comes to mind immediately.
If you use them to see whether your applications are running and/or working correctly, I'd ask whether you really want to see the status of all applications, or just a select few? In the latter case, you could use something like i3status' run_watch to watch for the existence of certain processes. This has the advantage that the status information will stay at the same place throughout reboots and the like.

Independent of all our opinions on status icons and the like, I also wanted to mention that GNOME has officially abandoned them, and this has probably an influence on the ecosystem outside of GNOME as well:
Most importantly, application developers close to the GNOME ecosystem will probably not implement status icons anymore, as they themselves can't even see them on their desktops.
This means, DE/WM developers outside of GNOME might also be more hesitant to work on status icon features, as a lot of apps will now not use them anymore.
KDE still has status icons though, so this might be dependent on how many "KDE-close" applications one uses.

[sersorrel]

Personally: being able to click icons is a desirable feature; I don't have the brainspace to memorise a keyboard shortcut for each of the indicator applets I use. I also don't want to have to write my own application to do something like display a list of WiFi networks, I have enough tiny custom scripts already.

Further, suggesting to use an i3status module (or similar) is a significant loss of functionality, since indicator applets can have colourful icons, which is significantly harder to do in i3status (even assuming that i3bar will properly display colour emoji, you still have to find a font which contains the characters you want to display).

It's also not reasonable to say that an i3bar-based solution is better because the icons will have a consistent order – there is no technical reason why i3bar cannot display tray icons in a deterministic order, it's just not implemented yet (there is a patch, but it's buggy, and I don't have the time or knowledge to debug it): #3573

In summary: yes, indicator applets suck, but all the alternatives I've seen proposed suck more. People still use indicator applets, so improving i3bar's handling of them seems like a sensible thing to do.

[reitzig]

2c: On my desktop PC, I could probably go without "notification area" icons (Flameshot, Redshit, Jetbrains Toolbox, Tresorit all require little interaction beyond opening the main windows --> Ctrl+D). On my work laptop, much more is going on: all of the above plus network manager applet, Bluetooth applet, Logitech Unifying applet -- some of which I frequently interact with.

Plus, if I ever were to create a UI interface to the numerous helper scripts or shell commands I have inadvertantly come to rely on with i3 -- say, a less crazy person wants to use my computer -- that would probably be the place to put a "start menu".

[kafran]

Question

Friends, how are you alternatively surviving without tray icons?

Context

I use i3 on top of a Mate DE replacing Marco for i3 on a Linux Mint installation (this is the way I found to get things up and running fast). I'm thinking to change to Mint XFCE on the next release and replace Xfwm for i3, because Caja has been bugging me a lot to run on a Mate Session with i3 as WM.

The problem

Problem is that both Mate and XFCE has been gradually migrating to systray I think are not based on XEmbed. On XFCE its even worse as important services like volume control has migrated from daemon to applet. Even nm-applet has to be launched with --no-indicator to properly work on i3bar.

The future

So, it seems systray is something that will not survive the future. SwayBar doesn't have a good support for it. Gnome has get rid of it... So, whats the future of systray icons? And how are you adapting to it from a UX perspective. I use systray mostly for enable/disable bluetooth and to pair new devices, to look for wifi networks, to see if my dropbox is running and synchronizing w/o problems, to clipboard management, and to power-management. How can I manage this without having to bend my brain?

So, question is: how are you alternatively surviving without systray icons and how could I adapt to this not far away future?

[steils]

Friends, how are you alternatively surviving without tray icons?

I use snixembed, https://git.sr.ht/~steef/snixembed

[stapelberg]

Okay, so to recap the current status:

• In 2015 it looked like this StatusNotifierItem is the future for trays. In the meantime, GNOME seems to have given up entirely on the concept of trays. What does adoption look like right now? Would we make possible any new use-case or better experience compared to today?

• The only thing currently speaking for adding support, IMO: Qt5 has a bug that results in rendering issues when using the older xembed protocol, so that might be worked around by implementing StatusNotifierItem.

• Given the complexity of e.g. Implement Tray Icons swaywm/sway#1234, and the fact that it seems like the only advantage is to work around a bug in Qt5, I’m tending towards not having this functionality in i3.

Is that accurate? Am I missing something?

[Airblader]

I still see a big demand for a tray among users and don't really understand or support Gnome's decision. Or, better put, I understand their motivation, but it misses some points which impact users, and users of window managers such as i3 even more so, IMO.

Whether or not SNI still provides a significant improvement here — I'm not so sure anymore. It does trade quite a lot of complexity for seemingly minor improvements. As with X itself, it seems doubtful that XEmbed is going anywhere anytime soon.

[stapelberg]

I fully agree!

[sersorrel]

I was under the impression that SNI would allow for the same tray to be displayed on multiple outputs, which would be a significant improvement over the current situation for users with multiple monitors.

[nlgranger]

My 2ct contribution for this discussion:

• Gnome works to integrate apps so as to avoid the need for trays. i3 doesn't provide integration for volume control, network, battery status, etc. which can be implemented via tray icons, so they are useful IMHO.
• snixembed readme seems to imply it won't be developed anymore.
• Supporting both Xembed and StatusNotifierItem is extra work for app developers, but libappindicator can help for supported languages.
• Adding StatusNotifierItem would bring more feature parity between sway and i3.
• Supporting SNI seems like a lot of work indeed, is there anything that can be reused from the work done on sway?

[hyiltiz]

What are the technical difficulties in implementing support for SNI along with the currently used XEmbed based tray icons? I don't think looking up to GNOME or others are much meaningful.

[orestisfl]

Nothing necessarily "hard" but a lot of code needs to be written/ported and then debugged & maintained. We are currently a bit conservative with implementing new features that might lead to new bugs because we have a reduced amount of time.

However, I am sure that if somebody is motivated enough to develop & maintain a patch for SNI for i3, it would find a lot of usage (myself included).

[hyiltiz]

I think it is at least a skeptical idea to follow GNOME rather than a standard even though that standard came from freedesktop, which is closely related to GNOME. As far as I could find out, the system panels/bars/trays from KDE, XFCE, LXQT as well as third party ones such as polybar all support SNI. To be able to attract contribution, it would be helpful if we can describe and propose a way to implement it (specific details such as which functions in xcb.c needs a SNI cousin, and at what level a wrapper function dispatches into SNI or XEmbed protocols etc.) That could significantly lower the bar for anyone interested to give it a try over a few weekends.

The following project, released under a permissive license, seems to provide a wrapper for SNI icons so they "act like" XEmbed style icons. In the worst case scenario, an i3 user compiles and runs this project (still trying; it didn't simply compile). A better way would be to maybe draw inspiration from these projects and some of the ones mentioned above so we could provide a minimal but ideally platform independent (not depending on gtk or qt libraries etc.) implementation.
https://git.sr.ht/~steef/snixembed

[psychon]

Since you mention snixembed, here is what happened when I took a look at it: awesomeWM/awesome#2995 (comment)

I also recommend reading the next post in that issue, because the snixembed author chimed in and wrote a bit about it.

The conclusion for me was: I cannot test my implementation, nothing follows the standard anyway, and the need for this protocol seems to have (partially) vanished. Thus, I stopped looking at it.

[Airblader]

Thanks @psychon. I have also long arrived at the conclusion that this is not worth implementing given the effort that has to go into it while considering the state of things.

Let's pull the plug on this.

[hyiltiz]

None of the KDE apps, including the one I care about such as Network Manager, KMix, Kgpg, blueman, and fcitx all now stopped showing their icons. I try not to use Electron apps, so I do not care much about them; I can imagine people saying the same to me about KDE apps, though.