Draft "StatusNotifierIcon" broken by design

[Wolfgang Draxinger]

Am Wed, 19 May 2010 22:35:58 +0200
schrieb Marco Martin <notmart at gmail.com>:

> it's StatusNotifierItem now, and yes, there are copies outdated out
> there, like the one on the wiki

I see, where can I find the most recent version?

> the crrect way would be dbus to support other transports, there was
> work being done on that, but i don't kno if it had any progress
> lately (that's why images are transported in network byte order in
> the spec, to be ready for such a case)

Well, I agree partially. DBus relies on dbus-daemon to setup the IPC
endpoits and do all the message passing work. X11 however already
provides certain IPC mechanisms. And then there's the question where
the dbus-daemon should run, most oftenly it will run on the system where
the session was started initially. OTOH it would make sense to have
such a daemon running on every system participating in the session:
DBus was designed as low latency, avoid-round-trips system, but if a
single dbus-daemon is running on a remote machine then this is broken.

I think a DBus-like IPC over X11 should be independent of DBus in the
first place, but it should also allow for DBus message passing. And
since X already provides all the IPC mechanisms, it would be good, if
one doesn't have to start such an additional daemon, if no DBus is
required, but XBus sufficient.

> the ones should be real applets at this point, of whatever the
> workspace will provide. this is the only way to have both a good
> integration with the workspace and all the flexibility needed
> in our case, the battery indicator and the network management ones
> are displayed in the systray for coherence, but they are indeed
> plasma widgets

Unfortunately such desktop environment specific applet mechanisms cause
some sort of vendor lock. For example I'd like to use the KDE
removeable storage device plasmoid in a XFCE panel, but Plasma and
XFCE don't mix, of course. Also I'd prefer if every applet ran as an
independent process, so that a single applet crashing won't take down
my whole desktop shell^1. It doesn't necessarily imply the use of
XEmbed, just look at how Chromium implements rendering into a single
window from multiple processes. Oh, and you can share XIDs between
processes, which allow for all sorts of cool tricks. For applets I
could think of either XEmbed, Composite if available, or drawing into a
ARGB pixmap, which is then drawn into the applet area, by the applet
manager. This is would also allow to run applets stand alone.


Wolfgang

[1] Happens often enough: I'm in user support of my universities
faculty of physics computer lab, and every day I've to deal with about
4 users, who's KDE Plasma crashed and are stuck.