comments on StatusNotifier spec

[Marco Martin]

this was an anwer thai I sent only to Dan by mistake 2 days ago,
posting here too for completeness

On Mon, Jan 18, 2010 at 11:06 PM, Dan Winship <danw at gnome.org> 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.

the application (and in particular the client library) will just
receive an activated, so all applications using the same library will
react in the way is defined, so yeah gnome apps using the "official"
library would all react by destroying the window, that's a fine
behaviour

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

it is not, we just designed to be flexible to accomodate -also- not
first class citizens

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

(open question) we could have some -recomended- scenarios for
different kind of implementations? like desktop use case, mobile use
case, text only...
i fear it would kill great part of the flexibility however
- Hide quoted text -

> 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
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>