comments on StatusNotifier spec
Aaron J. Seigo
aseigo at kde.org
Mon Jan 18 14:24:11 PST 2010
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
(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
> 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
> 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
More information about the xdg