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 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. 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. The current naming scheme /org/kde/... /net/... /com/sun/java/... 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.
signature.asc
Description: PGP signature
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
