Draft "StatusNotifierIcon" broken by design

[Wolfgang Draxinger]

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.

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
ICCCM:

> -- 1. Introduction --
> 
> It was an explicit design goal of X Version 11 to specify mechanism,
> not policy. As a result, a client that converses with the server
> using the protocol defined by the X Window System Protocol, Version
> 11 may operate correctly in isolation but may not coexist properly
> with others sharing the same server.
> 
> Being a good citizen in the X Version 11 world involves adhering to
> conventions that govern inter-client communications in the following
> areas: 

In this case I impeach xgd/freedesktop having a particular
brainchild, err hammer, named D-BUS and now the people involved try
doing about everything using that. There's nothing wrong with it per
se, but using it for inter X-client communication is just wrong. We got
ICE and ICCCM for that. Use it, it exists for a long time.
   D-BUS was introduced to have a concise system for IPC between system
and user session processes, or user processes not already running
within an environment, where a standard means of communication exists.

Don't get me wrong, I'm not against D-BUS. It is a very well designed
system with it's own proper set of applications. Of course there are
useful scenarios in which also X-clients may want to exchange data
using D-BUS - the best way to identify those is, doing the mind
experiment, if the programs in question may be running in different
sessions and there's still usefull stuff to communicate. If yes, then
use D-BUS, else if no, then use a simpler method that stays within the
session.

Some of the (proposed/draft) specifications on FreeDesktop.org are
highly redundant and some parts of their design have been deliberately
abandoned in existing specifications for good reason.

Mainly it boils down to: "Don't reinvent the wheel, especially if the
reinvention is inferior."


Just my 2 cents

Wolfgang