Proposing the StatusNotifier specification
Aaron J. Seigo
aseigo at kde.org
Wed Jan 6 13:24:58 PST 2010
On January 6, 2010, Giles Atkinson wrote:
> Thank you for your comments on those of mine. I agree that most of your
> remarks on item 1 make sense, but can not agree with "... Xembed seems
> pretty slow ...", as in this case it comes down to little more than
> reparenting a window.
it's not the reparenting of the window. it's getting the selection, finding
the windows, ensuring the visuals are right, etc. it all adds up and for us
got to the point where a typical system tray was taking longer to populate
than it took the rest of the desktop shell to get up and running. "fast
enough" was no longer, well, fast enough.
> And I was not clear what windows you are talking
> about here: "... and forcing argb visuals on those windows seems to cause
> several problems both in terms of graphic corruption or stability of the
here's the concrete use case: plasma-desktop uses an argb visual. most other
apps out there on x11 don't right now. fair enough. but they like to put icons
in the tray. so we reparent that xwindow and now have N windows with different
visuals. in the past, this wasn't a problem because nobody was doing anything
particularly interesting on x11 and just used the standard vanilla visual that
the server offered by default. well, when we started using an argb visual in
plasma-desktop (2+ years ago now) we found that there were all kinds of
glitches and bugs, including crashes, in the client libraries. we ended up
having to work around various Gtk+ crashes and Qt ended up fixing some bugs in
their code as well. in fact, we ended up including a new xatom (iirc?) to get
it work reasonably well and patching Gtk+ and Qt for that (upstream). it's a
mess. when you compare it with "here's the information on the bus, render it
as you wish" there's no competition.
> For item 2, my concern is that there is no generic, or catch-all category,
> so that potential clients that do not fit in one of the four listed
> categories are excluded.
do you have concrete examples? every app we looked at that puts an icon in the
tray (and there are dozens) fits into one of the existing categories; in fact,
that's how we came up with them.
i don't think there is much to be gained by having too many categories. it
only opens the door for app developers to abuse the sytem tray area and makes
management of it (from a user's pov) more complex.
> I assume that one purpose of the categories is
> to allow users some control of which clients are actually displayed. Such
> filtering should be under user control, not inherent in the specification
> of the notification mechanism.
with categorization, then the host can decide to show only items of a certain
type (think: messaging notifiers) and the user isn't required to understand
what each icon does/is. it also encourages *cough* the developers to think
about what they are doing and not just stuff random sillyness into what is
really a pretty precious space.
> On item 3, you wrote: "... well, exactly how to do that is kinda outside
> the scope of the notification, (besides recommending to use the old way as
> fallback)". My concern here is that the specification does not recommend
> using the old way, except when an active implementation of the new
> specification is not present. (At least, that is my reading of it.) That
> means that any older clients are ignored.
it just means that if there is a host visualization, that is the preferred
mechanism. older clients aren't ignored at all (at least if the host
visualization (e.g. system tray), doesn't suck). the goal is to deprecate, and
eventually get rid of, the old and broken xembed based system. we don't want
to encourage people to use the xembed system given how badly broken it is, but
we do realize that there are many xembed implementations out there (and will
be for some time) and it is important that everything works together during
the transition to the new and improved.
so there are four combinations:
* xembed host with StatusNotifierItem -> works, because the app falls back to
xembed as there is no StatusNotifierWatcher
* xembed host with xembed app -> works, obviously :)
* StatusNotifierWatcher visualization with xembed host -> works, as long as
the visualization also provides support for xembed as well
* StatusNotifierWatch with StatusNotifierITem -> works, obviously :)
so for the next while, we have to support both protocols on both client and
host sides. eventually, once all the main systems we care to care about have
StatusNotifierWatcher support, we can drop the xembed fallback on the client
side. and at some far future point we can probably do the same on the
visualization side (though that will likely take significantly longer)
the KDE Plasma Desktop has been doing this seamlessly since the 4.3 release.
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
More information about the xdg