comments on StatusNotifier spec

[Aaron J. Seigo]

On January 20, 2010, Michael Pyne wrote:
> On Wednesday 20 January 2010 12:10:44 Marco Martin wrote:
> > > 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
> 
> Well there's no reason we can't provide examples for how the various
> components (e.g. the title, icon) would be used in practice.

which would be ultimately unreliable given that visualizations may behave 
differently.

the common mistake here is to consider this spec as a design guide for system 
tray widgets. it's not. it is a description of how to get data from 
applications regarding their status to other applications which would like to 
integrate that data. a primary user of the data (at least right now) will be 
"traditional" system trays.

this is a shift towards a more service oriented environment and away from an 
overly prescribed system that welds the applications and the device 
environment so closely that we end up seeing people reimplement the entire 
thing everytime they want to do something even a little differently.

as examples of that, i give you Canonical's application indicators and Maemo's 
systray-like icons.

i think it's fine to define what the data published should look like so that 
both the entries and the visualizations of them can operate with greater 
confidence. but defining the visualization interaction patterns isn't going to 
fly.

application developers (and i'm one of them) simply have to get used to the 
idea of operating in environments that provide access to services and which 
craft the user experience appropriately for the context. this is the business 
of the primary user interface (desktop shell, netbook shell, etc) and not the 
applications. why? because applications will do it differently from each other 
(consistency issues) and only the primary user interface knows what is 
contextually appropriate (e.g. are we using a Dock or a taskbar+system tray; 
is it a desktop or a smartphone; etc...)

> for things like what
> signal do I need to use if I want to intercept the mouse wheel of the
> systray?

org.freedesktop.StatusNotifierItem.Scroll

we have tried to cover the needs of application development. really we have. 
because we are also application developers.

(and you shouldn't consider it in terms of "mouse wheel" but in terms of "my 
status entry has been asked to scroll, for whatever that means in the context 
of my status entry and application"; as you can see, the service concept is 
actually pretty symmetrical in that regard since visualizations don't get to 
interpret what scrolling results in :)

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