Draft "StatusNotifierIcon" broken by design
wdraxinger.maillist at draxit.de
Wed May 19 12:55:47 PDT 2010
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
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
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 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.
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.
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
i.e. self documenting names.
The current naming scheme
documents, who implemented it, but not, what it's doing. Now compare
that with the structure of your typical *nix filesystem.
Well, now we got that domain name based namespace, and probably are
stuck with it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the xdg