Draft "StatusNotifierIcon" broken by design
Aaron J. Seigo
aseigo at kde.org
Wed May 19 09:30:31 PDT 2010
On May 19, 2010, Wolfgang Draxinger wrote:
> 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.
Excuse me if I point out the obvious irony of someone creating the Nth window
manager who then goes on to complain about NIH :)
> This is my first of probably a series of rants to come, especially about
> what's going on with xdg.
I don't think anyone will be very interested in your rants unless the are
constructive, reasoned and are paired with effort and action on your part.
Please keep that in mind as you offer feedback.
> 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.
The answer: use the xembed fall back. Legacy systems without DBus don't get to
play as first class citizens in today's desktop world. There's a point where
trying to be infinitely backwards compatible comes at the cost of any useful
progress in the current day, and we have decided not to play that loser's
game. The number of people affected adversely by the xembed system is the
overwhelming majority; the number of people who run an app that needs a system
tray entry remotely from an xserver with no DBus is vanishingly small. And to
repeat: we still have the xembed protocol around as a fallback, even if it
does give poor results when used.
> 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.
The problems Marco mentioned in his email are inherent to the design for the
XEmbed systray and there is no way around it without completely dropping it
entirely and reinventing it from the ground up to be not broken with respect
to such things. That you don't see any issue with not being able to govern the
visualization of the entries, merge their information with items other than a
strictly traditional stystem tray, etc. probably means you're doing something
fairly traditional (which is perfectly alright, of course :). For others
working on modern systems, it can't fit the bill. See the recent thread about
the status notifiers from the fellow working on the OpenGL driven dock.
> 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.
From the same project that birthed the Status Notifier Items: we do use it
where it makes sense.
> 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.
That's part of it. DBus is also there for communicating between applications
running even in the same session. It's more expressive, easier to work with
and offers various useful features like introspection.
> 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.
I agree that we need to continue to work on, and in some cases re-work, the
specificaton on fd.o. I hope you'll join, productively and constructively, in
helping us achieve that. Thanks ...
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the xdg