comments on StatusNotifier spec
Aaron J. Seigo
aseigo at kde.org
Tue Jan 19 10:27:16 PST 2010
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
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
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
> 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,
> 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
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
More information about the xdg