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