System tray

[CIAvash]

Is providing a system tray as an internal block possible?

[geommer]

That is a good idea, and I spent sometime to learn about Xembed and SNI becuse I am totally ignorant of these things. But generally I am interested and this can very possibly be done with a conditional compilation flag in order to not bloat the source code.

[Airblader]

Please don't implement the Xembed based system tray specification. You get yourself in a lot of trouble only to support an outdated specification. Just implement the app indicator specification instead.

[HellishINC]

I too would like support for a system tray if/when you feel you can implement it to your liking.

[michaelmrose]

System tray is kind of a crummy interface and yet I wonder how many apps that use this feature are out there that don't support appindicator.

[Airblader]

Probably very few, useful ones anyway. Most probably use libappindicator which uses app indicators with a system tray fallback. Also, AFAIK all major desktop environments have dropped support for system tray already, so if an app doesn't support app indicators yet, it's pretty much unusable.

[flexd]

I am very interested in making this work. What do we need to make this happen?

[Airblader]

What do we need to make this happen?

Reading and understanding the specification would be a good start to get a feeling.

[flexd]

Reading and understanding the specification would be a good start to get a feeling.

Conceptually, it does not seem that difficult. Create a StatusNotifierHost, and register it with VOID org.freedesktop.StatusNotifierWatcher.RegisterStatusNotifierHost (STRING service);

and also listen to these two signals to know when to update the bar with info: BOOL org.freedesktop.StatusNotifierWatcher.StatusNotifierItemRegistered (STRING service); BOOL org.freedesktop.StatusNotifierWatcher.StatusNotifierItemUnregistered (STRING service);

That being said.. I have not coded C in years, and I don't exactly know where to begin.. glibc has a D-Bus implementation,

Something like this (psuedocode)

String statusNotifierHostName = "org.freedesktop.StatusNotifierHost-"
                                     + pid() + "-" + uniqueId();
registerToDBus(statusNotifierHostName);

StatusNotifierWatcherConnection watcher =    getDBusConnection("org.freedesktop.StatusNotifierWatcher");

watcher.registerStatusNotifierHost(statusNotifierHostName);

connect(watcher, SIGNAL(StatusNotifierItemRegistered()), this, SLOT(StatusNotifierItemRegistered()));
connect(watcher, SIGNAL(StatusNotifierItemUnregistered()), this, SLOT(ServiceUnRegistered()));

m_itemList = watcher.RegisteredStatusNotifierItems();

foreach (string service, m_itemList) {
    StatusNotifierItemConnection item = getDBusConnection(service);
    //we will have a slot called when the asyncronous GetAll() is done
    //it will create or update the actual visual representation of the item
    item.GetAll();
}

is an example from here http://www.notmart.org/misc/statusnotifieritem/scenario.html

[g4rrucho]

Is anyone interested in implementing this idea? I know how to code C but I don't know where to begin with this freedesktop thing.

[Cotix]

Same for me. Maybe if I have some free time this summer I'll take a look, but I doubt it..

[pmatos]

Just to confirm, is this a request to have a space where things like skype and other background processes stay? What's the current solution to yabar users? Is there an alternative?

[Cotix]

Yes. Current solution is not using yabar, but a different bar that supports system trays..

[CIAvash]

Or using a standalone system tray like trayer.

[ibrokemypie]

+1 watching

[68656c6c]

I would love to have this.

[ghost]

... meeeeeeehhhhhh

[Aloz1]

Just an aside with respect to SNI. It seems that "org.freedesktop.StatusNotifierItem" is used almost nowhere currently. Instead, KDE's "org.kde.StatusNotifierItem" is significantly more widespread. Canonical even use "org.kde.StatusNotifierItem" in libappindicator (it was changed to match the KDE spec in revision 106, way back in 2010).

Additionally, there appears to be a small utility called "xembed-sni-proxy" which allows XEmbed to function with SNI. Looking at the source to this application though, it is evident that it too uses "org.kde.StatusNotifierItem". Also, a quick search of "org.freedesktop.StatusNotifierItem" shows only 8 pieces of code on the whole of github, whereas "org.kde.StatusNotifierItem" 798 pieces of code (10x as many).

I really like the idea of SNI and as such, I'd be happy to have a bit of a crack at it. Seeing as the KDE variant is vastly more popular, perhaps that should be the starting point, as opposed to the freedesktop SNI? The freedesktop variant of SNI could always be added further on down the track if it were to gain more widespread popularity.

[NBonaparte]

The protocol is the same, the name is just different. All the implementations I've seen used org.kde.*, so that's the one which will be used. I've done some work in sni-tray and gdbus-sni-watcher. So far, I have the watcher complete, and the host needs to have rendering implemented IIRC. Unfortunately I haven't been able to work on it much recently.