Well, I had to cut a few corners, but Peter’s FVWM 2 config seems to look fairly sane on Ubuntu.

I nailed unity-2d-panel onto the system, and it looks ‘all right’, and has all the notification icons, which is hardly surprising as it’s unity-2d-panel that provides the panel to Unity2D – for whatever reason, I can’t get Unity running in 3D mode on Precise in my VirtualBox VM for it.

What I suppose I’ll extoll at this point is the virtues of standards, and I suppose this is the first time I probably ever have spoken about standards and interoperability on a *NIX.

There is a standard for how system tray objects are configured. This is a known fact. It’s name varies, but it is, if I recall correctly, an extension of EWMH. Given this fact, then, most modern window managers will support it by ignoring it; specialised applications such as trayer, stalonetray, etc., as well as, of course, panel applications such as the KDE, GNOME, XFce, LXDE panels all support this interface. That’s why it is something of a de facto standard.

Except, of course, GNOME (or rather, Canonical, developers of Unity and the now-defunct Unity2D) is above this petty standard interface. Instead, they implement their own abomination of an interface which requires one to implement yet another system tray standard.

Normally, the way that system tray objects are managed is through a mechanism I’ll choose to call Swallowing (mostly because fvwm supports this on normal windows). Without any window manager or system tray running, a system tray object is merely a standard X window (provided by whatever widget set, be it Gtk, Qt, or something else) which is placed on the screen.

In an ICCCM-non-compliant window manager, this will be given decorations. In an EWMH-non-compliant window manager, this will be undecorated but floating. In an EWMH-compliant window manager, chances are good that the window will be ‘invisible’ – that is, it is either rendered off the screen (due to a hint, perhaps?) or not rendered at all.

System trays (well, a provider for Swallowing system tray objects) look for certain window types flagging themselves as system tray objects. These objects are then Swallowed into the system tray, and thus an object is in the system tray, precisely where it’s expected to be. Don’t ask me for the exact mechanics of how this is done – I don’t know off-hand – but know that this is done in a standard way specified in the X11 protocol.

The trend for inserting items into panels in modern desktop environments, notably GNOME and derivatives – including Unity, which here means both the 2D and 3D variants of the same, because my Ubuntu VM and the target system don’t have Gallium llvmpipe (which is a damn’ fine technology!) and, in any case, predate the deseparation – is via DSOs.

The advantage of a DSO is that the runtime overheads are smaller. You only need (in an ideal world) one working set of big shared objects (e.g. Gtk+GNOME) per panel, as opposed to each application bringing their own working set and toolkit. The disadvantage is that you then need to implement the ABI and provide all the interfaces that the DSO expects to tell it where to draw, what colours it’s permitted to use and whatnot.

For standalone system tray providers like stalonetray and trayer, that’s a big disadvantage. You can’t just look at your Unity clock and go, “oh, I want that elsewhere”. It’s a shared object specific to whatever specification Unity have implemented for their system tray and panel objects. To add confusion to the injury, all of the default system tray objects in Unity out of the box run additional helper processes with doubleplus-unhelpful names – to the experienced UNIXer (and I can say this with confidence, having seen this happen in real life) simply launching these helpers separately to the session just doesn’t work as expected. Bye, POLA.

And, for bonus points, Unity’s panels refer to something called ‘legacy indicators’ – indicators being their fancy word for system tray objects – and can you guess what ‘legacy’ means? Oh, yes, that’s right. Window swallowing. This, naturally, allows for very useful (for a certain definition of useful with which many may disagree) so-called legacy applications such as the NetworkManager applet and a variety of others to work, theoretically seamlessly, and in the vast majority of cases, that’s true.

Still, why do they call it ‘legacy’? Are they implying it’s deprecated and support will be phased out? That won’t be a popular move, even by Canonical’s standards.

Which reminds me, I really want to see a system tray object implemented in plain Xaw.