Draft "StatusNotifierIcon" broken by design

[Marco Martin]

On Wednesday 19 May 2010, Wolfgang Draxinger wrote:
> Hello.
> 
> Right now I'm implementing my own window manager. Mainly because I'm
> not satisfied, what existing WMs provide or the way I have to configure
> those WMs which are closely to what I like. And the later unfortunately
> don't all implement things you need in a modern desktop.
> 
> So I'm reading the specifications about X11/X.org and
> FreeDesktop.org - and at times went WTF?! to some higher power,
> because of, well... TSWAHELLAN and NIH.
> 
> This is my first of probably a series of rants to come, especially about
> what's going on with xdg. My concerns are mainly attributes to the "to
> someone with a hammer, everything looks like a nail" (TSWAHELLAN) and
> "not invented here" (NIH) problems of the xdg folks.
> 
> I'd like you to look at
> <http://www.freedesktop.org/wiki/Specifications/StatusNotifierIcon>
> specifically at
> <http://www.notmart.org/misc/statusnotifieritem/basic-design.html>
> 
> | The Status Notifier Item system relies on inter-process communication
> | via D-BUS and is composed by three parts: (...)
> 
> And then think about this:
> 
> xinit /sbin/ssh -X $REMOTEHOST $START_DESKTOP_SESSION_CMD
> 
> or, even just something simple like
> 
> ssh -X $REMOTEHOST $SOME_PROGRAM_USING_THE_SYSTRAY
> 
> from a running X session. D-BUS won't work here, because SSH doesn't
> tunnel it. Oh yes, SSH could be expanded to implement it. But then
> there's the next problem: What about connecting from a X server/system
> where there's no D-BUS? Yes, those exists, and they're plenty.

that's why the specification still requires a seamless fallback to the xembed 
version

> I understand, that there are some issues with the current systray
> mechanism, the biggest I agree with is about interaction with modality.
> But I highly disagree with the way how the proposed specification
> addresses this.
> 
> And let's face it, the current XEmbed systray does it's job quite well,
> and the problem is not that systray is inherently flawed, but that the
> programs using it have bugs or don't conform. Let me cite from the

does its job if you want a "system tray" in the most classic sense of the word 
with all its limitations, that we felt completely failed from an user 
interaction point of view.

- being limited to show an icon, no alternative representations, no more than 
one
- being forced to do exactly the representation the application choses (in 
theory embedded windows should be resizable, in practice no one is)
- little to no communication between the icon and the host, on what it is its 
status, importance, category etc (yes, a limited one could be achieved with 
atoms, but that one would really be the hammer that adresses a non nail 
problem)

moderm canvas-based visualizations really need to be able to paint the icons 
themselves (or what they decide it is the best represetation, maybe not icons 
at all)
what we need is a model-view based approach, that really provides informations 
about applications,  where is completely up to the workspace to decide how to 
present that information (if at all) to the user
all tose considerations put xembed out of the game, except as a legacy 
falback, that is -not- going away, so you are perfectly free to not support 
this specification.

Cheers,
Marco Martin