comments on StatusNotifier spec

[Dan Winship]

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?

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

Having the visualization be in control of presentation is great, but you
need to give the app authors *something*. 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. And so the
StatusNotifierIcon would have to be entirely redundant with
functionality that was also provided elsewhere.

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. We need (IMHO) a spec that makes a good
set of guarantees to *both* sides.

-- Dan