Proposing the StatusNotifier specification

[Aaron J. Seigo]

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
> apps".

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