comments on StatusNotifier spec

[Aaron J. Seigo]

On January 18, 2010, you wrote:
> On 01/18/2010 03:12 PM, Aaron J. Seigo wrote:
> >> Also, you need to give *some* indication of what this is for. Eg,
> >> currently it could mean anything from "Please raise the indicated window
> >> if the user clicks on the status item" to "Please hide the indicated
> >> window if the user clicks on the status item".
> > 
> > yes, that's up to the visualization. the point isn't to state what is
> > done with the information, just to make that information reliably
> > available.
> 
> Let me try this again. Suppose you have:
> 
>     - KDE implementation: If WindowId is set, then raise that window to
>       the top if the user clicks on the status icon.
> 
>     - GNOME implementation: If WindowId is set, then *destroy* that
>       window if the user clicks on the status icon.
> 
> You are saying this is perfectly legitimate and StatusNotifierIcons are
> expected to cope with it?

yes. ignoring that the example given is a bit absurd, it is completely within 
the realm of possibility.

> > i'm afraid that you are missing one of the primary points of this
> > specification, which is that the visualization is in control of
> > presentation. the visualization may instead play a sound, for instance;
> > showing the attention icon in the case of an audio-only system (for
> > sight impaired usage or for systems that simply don't have a visual
> > output system) would be a bit silly, no?
> 
> If audio-only systems were actually a first-class use case, then this is
> not the spec you would have come up with.

i never said it was a first-class use case. it's a possible use case, and one 
that we kept in mind as we went. the primary (or "first class", if you wish) 
use case is a visual representation since that's the status quo and likely to 
be the most common going forward simply due to issue of utility. so the spec 
certainly has a lot of visually oriented information in it, but it's also 
possible to build an audio-only analog with it. which is pretty neat and even 
useful.

(i do think that if/when someone does such a thing, we may find ourselves with 
requests to augment the spec with audio hints as well; we'll cross that bridge 
when we come to it, though, and the non-pixmap related information may be 
enough in any case)

> Having the visualization be in control of presentation is great, but you
> need to give the app authors *something*.

we give app developers a way to export a set of data. that's precisely the 
extent of we intend to do. what do you feel the app authors need that more 
than that?

> Right now, the spec basically
> says "here are some methods you can call, but there's no way of knowing
> what will happen when you do". An application can't use
> StatusNotifierIcon for any part of its UI that it actually cares about,
> because it's possible that the StatusNotifierHost will ignore exactly
> the parts of the spec that are the most critical to the app.

yes, that would be the desired effect of encouraging application developers to 
stop abusing the system tray for things it really isn't meant for while 
simultaneously making it impossible to offer alternatives. from the 
perspective of the people who work on the desktop shell, if you rely on 
behaviour that isn't in that spec, you, as an app developer, are doing it 
wrong. i can understand why app developers want to abuse the system tray, but 
it is abuse and it leads to untenable situations for our users. we are not 
here to enable poor results, even if app developers are used to it being 
otherwise :)

> And so the
> StatusNotifierIcon would have to be entirely redundant with
> functionality that was also provided elsewhere.

can you provide concrete use cases? otherwise there is no way to actually 
discuss this point.
 
> In the current (XEMBED) system, the app has all of the control, and the
> tray is screwed, which sucks for the tray (and by extension, the
> desktop). But flipping things around so that the apps are screwed
> instead isn't an improvement. 

i have to disagree; the application is in complete control over the data that 
is represented. which is what it should have control over. the application is 
not "screwed" in any way similar to the way the xembed system represents. this 
is about taking the parts of the system that belong in the desktop shell and 
putting them there and the parts of the system that belong in the app and 
keeping them there.

> We need (IMHO) a spec that makes a good
> set of guarantees to *both* sides.

which is what we've tried to do; if you can provide concrete use cases that 
aren't serviced, that would be most helpful.

and yes, some uses of the system tray today are unacceptable abuses and we 
have zero intention of making the new spec encourage such behavior in future. 
the spec is already more complex than it "needs" to be to ensure we capture as 
much of the form and function of the system tray as we know it, but it is not 
intended to be a 1:1 clone of it.

-- 
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