comments on StatusNotifier spec
Aaron J. Seigo
aseigo at kde.org
Mon Jan 18 15:27:51 PST 2010
On January 18, 2010, Aaron J. Seigo wrote:
> On January 18, 2010, you 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.
> > 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.
i should clarify a bit here: such behaviour would be rather bizarre on the
part of the visualization and would really make no sense from a usability
perspective. so i don't expect apps to have to deal with "my window just got
destroyed because i passed it to the status item by id" or other such oddities
however, the _reason_ for allowing such oddities to even be plausible is so
that the results of interaction with the status item in the visualization is
*consistent* between applications. the only way to be sure of that is to put
the decisions in the hands of the visualization.
when we look at what Canonical is doing with their implementation of a
StatusNotifierHost, it's sensible (within the scope/aims of their design) but
rather different from what may (and does) happen in other implementations. the
only reason this is possible, allowing them to create consistencies within
their user experience that they are aiming for, is because the decision making
happens in the visualization and no applications need to be tweaked or prodded
differently at the source code level.
yes, this is a (small) shift in thinking on the part of application code (the
separation of data and visualization for the system tray), but the status quo
is broken and inferior and it's time we made this small shift in thinking.
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