Draft "StatusNotifierIcon" broken by design

[Oswald Buddenhagen]

On Wed, May 19, 2010 at 09:42:30AM -0700, Aaron J. Seigo wrote:
> On May 19, 2010, Oswald Buddenhagen wrote:
> > great prospects for those who actually try to take adavantage of x's
> > inherent networking transparency (the price of which one has to pay
> > anyway): crap notifier items or no notifier items. wow. that's progress.
> 
> Given that "crap notifier items" are the status quo which nobody had bothered 
> to do anything to (e.g. improve) for years (even after I first noted their 
> flaws to the people involved ~6 years ago), it's not a regression. At the very 
> least we've improved the (in practice overwhelmingly) common case 
> signficantly.
> 
yes. the problem is that the spec simply does not consider the cases
outlined by wolfgang and me. in at least one of them, the fallback won't
be activated, because the d-bus method will *appear* to be available.
havoc will ensue.

at the very least, the spec should go into *lots* of detail about
activating the fallback under untypical conditions.

> The reality, however, is that what you point out won't affect only
> notifier items, but all communication done over DBus.
>
yes. but from that you can subtract the cases which shouldn't have been
done via d-bus in the first place (thinking about the screensaver spec
in particular).

> It's a more general problem that will only be addressed by making it
> easy (as in "transparent") to route DBus over the same network that
> the X session is on.
> 
yes, and it's a hard problem. questions of session, seat, host and
display relation need to be answered, let alone actually implementing
the requirements.
i for one would prefer solving the fundamental problem before building
upon it. 
but then, maybe the 99%-solutions are good enough - apparently there are
acceptable (even if somewhat inferior) alternatives to the outright
broken scenarios, as no-one cared to really address the mess with
sufficient manpower.