Proposing the StatusNotifier specification
Giles.Atkinson at eu.citrix.com
Tue Jan 19 05:44:30 PST 2010
I have been out of this discussion for a few days, but feel there are still many unresolved issues. On January 6, in reference to the limited set of 4 notification categories in the specification, you wrote:
> 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.
Yes, I do and it is not an isolated case, but an example of a reasonable class of applications: those that present foreign windows from another environment and wish to integrate them as smoothly as possible with the local environment. This class potentially includes remote graphics applications, VM hypervisors and emulators such as WINE. (At the edge of it are straightforward applications using X remote display, whose use of the replacement notification interface is blocked by the sole use of D-bus.)
Applications in this class only have the information about their notification items that they get through the underlying foreign interfaces, and that is very unlikely to include anything that approximates the four categories. That could be interpreted as meaning they are barred from this interface, but in practice the application developers will simply make them lie. That seems unfortunate. This may be an example of what you are calling abuse, but to the users of such application it looks very different.
On the subject of backward-compatibility you also wrote:
... 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
That is all very well, and what anyone might want to hear, but it is not what is in the specification. As I have already mentioned, the specification is completely silent on compatibility with older clients, implying it is not an issue. The addition of a single sentence would fix that.
It is also silent on the motivation for the design (which still looks weak to me) and the semantics of the operations parameters, as Matthias has pointed out in another thread.
From: xdg-bounces at lists.freedesktop.org [mailto:xdg-bounces at lists.freedesktop.org] On Behalf Of Aaron J. Seigo
Sent: 06 January 2010 21:25
To: xdg at lists.freedesktop.org
Subject: Re: Proposing the StatusNotifier specification
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
xdg mailing list
xdg at lists.freedesktop.org
More information about the xdg