Comment 27 for bug 974480

James: I think a lot of it is about "works with Ubuntu" vs. "works against some APIs that were made 10 years ago, and which most/some Unices' Windows Managers have supported at some time". For stuff to work with *the Ubuntu experience* some effort will be required; this is much the same as following the HIG on Mac OSX. [*]

I'm tempted to suggest that the way to go with this is to have a separate application (_not_ part of the Unity, or Ubuntu APIs) which provides a implementation of the tray manager end per:

  http://www.freedesktop.org/wiki/Specifications/systemtray-spec

and which punts those requestes to a "regular" application window near a corner. Anything using the Systray API is not introspectable, it's not accessible and it's not really suitable for providing the depth of metadata necessary for the interface or for those who cannot see a grid of pixels. However, a separate implementation of the tray manager API would provide a legacy solution, and the .deb Recommends can pull in that shim when it's required so that it's only installed when such applications are pulled in.

[*] The counter for this would be that both Microsoft and the Linux kernel have succeeded for twenty years with prioritising mostly-reliable handling of previous generations of APIs. A separate shim application here would provide somewhere reasonably sandboxed to let legacy apps draw into their legacy raw container windows, while making it clear that these aren't a "supported" solution going forward, and importantly would get that code out of the Unity menubar implementation.