comments on StatusNotifier spec

[Aaron J. Seigo]

On January 19, 2010, you wrote:
> On 01/18/2010 05:24 PM, Aaron J. Seigo wrote:
> >> 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.
> 
> How is it absurd? Both of those two behaviors are things that window
> managers do under certain circumstances, so neither is an intrinsically
> absurd behavior.

under which sensible circumstances would a system tray destroy the window if 
the use clicked on the icon? it just doesn't seem like any reasonably designed 
system tray would ever implement this. we aren't dealing with random or 
malicious system trays roaming the desktop ;)

certainly, one might expect a "[quit | close] application" menu entry in, say, 
a context menu. those actually exist in system tray implementations.

> And nothing in the spec suggests that either of those
> behaviors is either recommended or discouraged.

yes, that's not the role of the spec which defines the mechanisms for 
communication rather than the design of the visualizations. this is purposeful 
to allow flexibility in the realization of visualizations. we plan, for 
instance, to eventually provide a feature that automatically merges status 
notifier items with entries in the relevant task bar entries (for which the 
window id and PID information is pretty useful). that's a visualization that 
is significantly different from the standard system tray and the kind of thing 
we want to be left open. so we purposefully did not tread on the 
visualization, but instead concentrated only on the data representation and 
transmission.

this is actually a rather basic/fundamental design methodology :)

> So how is the
> implementer supposed to know that one of those two ideas is absurd?

common sense. if they can't figure that out when implementing a system tray 
visualization, then i'd suggest you shouldn't be using their software.

i'm not sure a discussion about the possible absurdities we can imagine one 
doing with a system tray interface is particularly useful. if there is a 
security issue, sure, let's discuss that. but if it's simply a matter of "holy 
crap, imagine if someone made a really stupid system tray!" we have better 
things to discuss, don't we?

or, if you really do consider it to be an issue, i'd perhaps suggest that 
those who feel it is a real concern worthy of time and effort put into it 
formulate a "expected/best practices" document relating to system tray 
visualization behaviors that documents both what is common and expected and 
what would be absurd. then people implementing new system tray visualizations 
could reference that document to augment their common sense and design goals.

the spec we're discussing here is focused on the mechanism of communication, 
however. not the interaction details of the visualizations themselves. and to 
repeat: that is purposeful.

> Of course the idea that one implementation would do one thing and
> another would do the other is absurd, but that's exactly my point; the
> spec encourages this sort of absurdity.

i don't think that implementations doing different things is absurd at all. i 
think implementations doing absurd things is absurd, but different is not 
necessarily absurd. in fact, the ability to present the information in new 
ways, including with new (and hopefully improved) interaction systems is one 
of the goals of this spec. this is something that was not possible with the 
xembed system but now is quite possible.

Canonical is doing just that, in fact, to achieve their design goals, which 
happen to be different from those of the Plasma team in KDE.

the very cool thing about this is that the applications neither need to care 
nor notice! the user of the system is able to interact with these applications 
on the terms of the desktop shell and the applications still get exactly what 
they expect: their information shown and certain types of interactivity made 
available to the user.

> > we give app developers a way to export a set of data. that's precisely
> > the extent of we intend to do. what do you feel the app authors need
> > that more than that?
> 
> Knowledge of what's going to happen with that data!

why does the application need to know what will happen with the data? what are 
the use cases where this matters? does the app care whether an icon is shown 
or the name is read out to the user? does the app care whether the icon is 
18px or 24px?

there are some things that the app does care about indeed. for instance, if 
the application has some urgency to its status, it needs to be able to 
communicate that. this is why the spec includes that information. 

now, if the visualization, due to its design goals, decides that such 
information is not appropriate to communicate on, that is something that is up 
to the visualization's design. the application can simply not know when that 
is sensible contextually (leading to various unfortunate circumstances with 
the old system tray such as the inability to offer sensible auto-hiding 
semantics). and yes, if the visualization makes poor decisions, then it's a 
problem in the visualization. the application, however, does not come into 
play there, and i guarantee you that most if not all visualizations will not 
screw up in this way because the entire point of providing a system tray is 
utility (within the design goals of the particular user interface shell)

i'm very interested in the _end results_ for the user, and with this spec we 
have been able to achieve greater _end results_ with more consistency, control 
and expresivity for the user.

this is a direct result of divorcing the application from the visualization.

> If all they want to
> do is "export data", they can use printf.

and how does printf end up in a system tray? 

> >> And so the
> >> StatusNotifierIcon would have to be entirely redundant with
> >> functionality that was also provided elsewhere.
> > 
> > can you provide concrete use cases? otherwise there is no way to actually
> > discuss this point.
> 
> OK, you mentioned volume indicators in another email.
> 
> So, presumably I would want to have a series of icons for different
> sound volumes, and some way of indicating "muted". Let's say I want to
> indicate mute by overlaying a red X over the existing volume icon (so
> that the user can still see under the X whether the volume would be loud
> or quiet if he unmuted it).
> 
> The seemingly-obvious way that the spec offers for doing this is to use
> OverlayIconName or OverlayIconPixmap. Now, the first problem is that I
> can't actually control *where* the overlay shows, so maybe the X will be
> drawn in the worst possible position, and make it impossible to see the
> important part of the underlying icon.

this could be addressed by noting in the spec where on the icon the overlay 
should be painted by the visualization when compositing the two. right now we 
paint the overlay in the bottom right of the icon. this could be moved to the 
bottom left if desired. for consistency and simplicity, i don't think the 
overlay location should be mandated by the StatusNotifierItem. 

would that be an palatable answer to this particular issue for you: mandating 
in the spec where the overlay should be positioned on the main icon? if so, 
should we go with bottom right, bottom left, or?

> But that's a minor problem
> compared to the fact that there is no guarantee that the visualization
> will show the overlay *at all*. And obviously I don't want it to be the
> case that with *some* StatusNotifierHosts, "full volume" and "currently
> muted but previously full volume" would look exactly the same. So this
> means I have to simply ignore OverlayIconName/OverlayIconPixmap and do
> something else instead. (Either precompose the overlaid icons and use a
> separate IconName/IconPixmap for each, or else not use an overlay to
> indicate mute.)

so the question is whether or not a visualization that does not show the 
overlay is considered buggy. if it was a system tray as we know them now, i'd 
say "yes" and consider that a problem in the visualization's implementation. i 
also don't think that's a realistic concern, and isn't something this spec 
ought to try and cover.

if we consider non-traditional visualizations (e.g. things that aren't "system 
trays") it might very well make sense not to use the overlay icon. that is 
really something that is up to what the visualization is trying to externalize 
and how.

what i think we probably agree on is that the spec allows for someone writing 
a visualization to make a poor decision. where we differ is that i think this 
is something that we can reasonably rely on implementers to be skilled enough 
to avoid and that allowing for such flexibility allows for innovation, whereas 
you believe that without an ironclad guarantee that implementers won't be 
idiots that application developers will revolt.

> I'm assuming your argument is something like "but the tray may want to
> enforce strict restrictions on how icons look, so as to preserve a
> consistent visual style, etc etc etc". And that's a perfectly reasonable
> goal. But saying "you can set this property, but sometimes it will be
> ignored" is an awful way of implementing that goal, because from the
> application side, it translates to "you can only use this property to
> display information that is *completely unimportant* to the user".

not at all; the point is that the application should expect the visualization 
to use all the information available in the best way possible in the context o 
the design goals of that visualization. the application need not *care* how 
the visualization uses that data in the specifics because the assumption is 
that the user is being well attended to in their particular circumstances by 
that particular visualization.

it is not up to the application to dictate whether or not the desktop shell 
(as one example; it could also be a mobile phone or whatever just as easily) 
serves the user well or not. and i think that users will select environments 
that work well and abandon those written by people who can't get rather simple 
things right like showing an overlay when appropriate.

in any case, while i don't think your concern will see any occurrence in 
reality and will add verbage to the spec that probably is unnecessary as a 
result, i'd be fine with adding to the spec that if the main icon is shown and 
there is a valid overlay also defined that the overlay must be shown in 
conjunction with the main icon when shown as part of an informational display 
or part of an interactive area.

does that work for you?

> (There isn't even any way for the application to *know* whether or not
> the overlay is being/will be displayed.) It would be better to simply
> remove the property entirely.

because it's possible to write a poorly performing visualization we should 
neuter all of them? seriously?

> As I understand what you have said, there
> is absolutely *nothing* you can do with the spec that is guaranteed to
> have any effect.

yes and no. the application is guaranteed to have the ability to publish data 
which is to be used in the representation (visualization) of that 
application's status to the user. what isn't guaranteed is what the 
visualization will specifically look like or how it will implement the user 
interaction facilities in fine detail.

if you do not see the benefit of this (consistency by putting the decision 
making in one place so all entries are treated equally; flexibility such that 
we are not stuck with "one item, one tray" or "the item must be a painted 
artifact on the screen") then we really probably don't have much to discuss 
here. by those same metrics, model/view semantics are rubbish and that 
application code should always meld data and painting code into one block or 
that web servers should not send across structured data but entire images to 
be shown in the web browser.

you seem to be viewing the system tray from the old perspective that it's the 
application's own sacred location and it must be in complete control at all 
times. this has led to chaos and rampant inconsistency in the system tray and 
absolutely no ability to improve or alter how the system tray is presented. 
it's a BROKEN idea.

if you wish to stick to the data-and-visualization-must-travel-together 
concept where the application defines the visualization, we really don't have 
much to discuss and i wish you the best of luck with creating a modern desktop 
shell.

> The icon is not guaranteed to be shown,

correct. the user may want it to be hidden (though the application can 
advertise it has urgency or other transitory information) or the system tray 
may not be icon oriented at all. the icon may be in a menu attached to a task 
bar entry. etc, etc, etc.

> the urgency
> hint is not guaranteed to have an effect,

correct; that is up to the visualization to determine how it is appropriate to 
respond to that information. this is something only the visualization can 
know, and different visualizations may treat it differently and be completely 
self-consistent and well serving to the user.

> the tooltip is not guaranteed to be shown,

there may be nothing to show the tooltip over.

> there's no guarantee you can Activate the item

if the visualization is intended to be a place that the user can activate the 
item, then it will provide that feature. that may not make sense in all 
visualizations and so there is no point in forcing that on all visualization.

realize that there may be multiple simultaneous visualizations of the item at 
once, and different ones will likely provide for different, even simultaneous, 
purposes.

> So how can an application author possibly use this spec?

by publishing the data from their application as defined in the spec and 
expecting the environment the application is running in to be well suited to 
the user experience. yes, that means that application developers need to trust 
the primary user interface (e.g. a desktop shell) to be sane. i don't think 
that's too much to ask.

on the other side, when applications have too much control over the 
visualization details, then the people writing the primary user interface have 
no ability to do their job because they are now hamstrung by N different 
applications doing things in M subtly different ways and with no ability to 
adjust even the simplest of things like "is it appropriate that i show the 
icon now?" or "can i make the icons larger?" or "can i rotate the 
representation?"

application developers need to get out of the business of trying to define the 
primary user interface.

> (Answer: by targeting
> a single desktop environment and assuming that the StatusNotifierHost
> will behave exactly like that desktop's StatusNotifierHost is known to
> behave. And in that case you don't need an FDO spec.)

no, by writing to the spec (which means publishing the status data reliably) 
and then relying on the other components in the system (e.g. the 
visualizations) to do their job equally well.

we can indeed invent a world in our heads where this won't work because the 
desktop shell is out to get us and the people who write it are idiots and the 
people who use it have no choices in the matter. that world doesn't exist.

reality is that this spec gives applications access to an important kind of 
facility and the people writing the desktop shell the ability to craft the 
resulting user experience.

this is not unlike window managers which vary from tiling managers to free 
positioning managers with a z ordering, from managers that can group windows 
to those that can't, from managers that provide different mouse focus policies 
or even focus stealing preventing. it's about putting the control over 
presentation in the place(s) where we can guarantee consistency as well as the 
ability to continue to improve without patching every single application.

if you completely disagree with that design philosophy then you will indeed 
never be satisfied with this spec, we can all go our separate ways and we can 
see which approach pans out the best. on the other hand if you see value in 
such a design approach, we can continue to address issues one by one, 
presenting use cases and collecting issues for alteration in the spec to 
tighten it up. i'm quite interested in doing the latter, but i'm not 
interested in extending a "is model/view a good idea" debate.

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