comments on StatusNotifier spec

[Dan Winship]

On 01/18/2010 05:24 PM, Aaron J. Seigo wrote:
>> 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.

How is it absurd? Both of those two behaviors are things that window
managers do under certain circumstances, so neither is an intrinsically
absurd behavior. And nothing in the spec suggests that either of those
behaviors is either recommended or discouraged. So how is the
implementer supposed to know that one of those two ideas is absurd? (Or
are they both absurd? I don't even know.)

Of course the idea that one implementation would do one thing and
another would do the other is absurd, but that's exactly my point; the
spec encourages this sort of absurdity.

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

Knowledge of what's going to happen with that data! If all they want to
do is "export data", they can use printf.

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

OK, you mentioned volume indicators in another email.

So, presumably I would want to have a series of icons for different
sound volumes, and some way of indicating "muted". Let's say I want to
indicate mute by overlaying a red X over the existing volume icon (so
that the user can still see under the X whether the volume would be loud
or quiet if he unmuted it).

The seemingly-obvious way that the spec offers for doing this is to use
OverlayIconName or OverlayIconPixmap. Now, the first problem is that I
can't actually control *where* the overlay shows, so maybe the X will be
drawn in the worst possible position, and make it impossible to see the
important part of the underlying icon. But that's a minor problem
compared to the fact that there is no guarantee that the visualization
will show the overlay *at all*. And obviously I don't want it to be the
case that with *some* StatusNotifierHosts, "full volume" and "currently
muted but previously full volume" would look exactly the same. So this
means I have to simply ignore OverlayIconName/OverlayIconPixmap and do
something else instead. (Either precompose the overlaid icons and use a
separate IconName/IconPixmap for each, or else not use an overlay to
indicate mute.)

I'm assuming your argument is something like "but the tray may want to
enforce strict restrictions on how icons look, so as to preserve a
consistent visual style, etc etc etc". And that's a perfectly reasonable
goal. But saying "you can set this property, but sometimes it will be
ignored" is an awful way of implementing that goal, because from the
application side, it translates to "you can only use this property to
display information that is *completely unimportant* to the user".
(There isn't even any way for the application to *know* whether or not
the overlay is being/will be displayed.) It would be better to simply
remove the property entirely.

And so on throughout the spec. As I understand what you have said, there
is absolutely *nothing* you can do with the spec that is guaranteed to
have any effect. The icon is not guaranteed to be shown, the urgency
hint is not guaranteed to have an effect, the tooltip is not guaranteed
to be shown, there's no guarantee you can Activate the item, etc. So how
can an application author possibly use this spec? (Answer: by targeting
a single desktop environment and assuming that the StatusNotifierHost
will behave exactly like that desktop's StatusNotifierHost is known to
behave. And in that case you don't need an FDO spec.)

-- Dan