Am Wed, 19 May 2010 22:35:58 +0200 schrieb Marco Martin <[email protected]>:
> 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. _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
