comments on StatusNotifier spec

[Aaron J. Seigo]

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

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