Draft "StatusNotifierIcon" broken by design

[Marco Martin]

On Wednesday 19 May 2010, Wolfgang Draxinger wrote:
> On the way home I thought a bit about this, and I realized something:
> We're dealing with two totally different concepts here. One is are
> status areas (I'm not calling them icons) tied to programs with their
> own GUI, and general purpose notifications (like network status, system
> diagnostics, etc.).
> 
> For general purpose messaging a system like "StatusNotifierIcon" is the
> most appropriate solution, however I'd call it "StatusNotifier" (not
> -Icon). I still think, that any StatusNotifier should not connect

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

> directly to DBus, but use some session/screen aware transport. And upon
> starting a session, establishing a SSH tunnel, etc. a XBus<->DBus
> connector is started to connect screen/session agnostic bus to a
> display aware system. I.e. two layers:
> * display bus
> * message bus

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)

> The other are mini applets which are highly application specific. And
> those you will never be able to map all of them into a unified
> look-and-feel status notifier system, because there always might appear
> a program which requires some elements, which can't be implemented in a
> elegant way through a limited set of markup-widgets.
>

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

> I'm going to look into how a XBus could be implemented in a elegant
> way. I'm thinking about ICCCM extended with a object oriented
> messaging model and an easy to use API and frontend library.
> 
> 
> Wolfgang
> 
> P.S.: There's one thing I don't like, which also DBus has: Allocating
> the namespace based on domain names. I'd prefer to have the names being
> semantically chosen, something like
> /sys/net/...
> /app/desktop/...
> /session/...
> i.e. self documenting names.

would be really cool. problem is in the real world the name simply belongs to 
who arrives first, so domain names are the only real way to minimize conflicts

Cheers,
Marco Martin