New property proposal for StatusNotifierItem protocol: Label

[Ted Gould]

On Tue, 2010-08-10 at 09:40 -0700, Aaron J. Seigo wrote:
> i really think this is one of those places where we should draw a line in
> the sand and say "beyond this point, text doesn't happen, sorry." getting
> rid of textual data in the primary display of these items is a good thing,
> not a bad thing. it allows the user to tell _at a glance_ what is going on.
>  adding bunches of text erodes that.
> 
> and if i want to know to the exact % how my battery is doing, i can mouse
>  over it.

I think that you're conflicted here saying "at a glance" and "mouse
over." :)  I think the issue here is how precise of information you can
get at a glance.  With an icon you can get a round about idea, but a
number can give you much more information at a glance.

The other issue that we have is that in our visualization we're not
supporting tooltips.  So there is no mouse over for more information.
We could use the tooltip and put it on the panel, but it seems like in
general the tooltip in KNSI is designed for much more information than
"100%" so it doesn't seem like a good match.

> then again, perhaps you have some very specific visual design ideas that
> aren't being communicated well given that we are using text. if you have
> some mockups to share that would be illustrative in this case, please feel
>  free to share them :)

I don't have any mockups but the three people that are bugging me the
most about it are:

      * Keyboard layout.  They want to use text to describe the keyboard
        layout.  Currently in GNOME a couple of letters are put into an
        icon and frequently those have to be squeezed to make them fit.
        It would be better to use "standard text" in this case.
      * Weather.  There is a group of developers that is making a
        weather indicator with the intention of it being in the unity
        panel.  It would have an icon that is the type of weather
        (cloudy, sunny, etc.) and then provide the temperature as a
        label.
      * Power.  An icon that would be the approximate battery level, but
        also accompanied by a percentage.  While I'm also skeptical on
        the value of having the label there constantly, there is a very
        passionate group behind it.  And, I was also shocked to find out
        even Apple was unable to subdue them :)

There are a couple of other folks that I have approached me on the
topic.  They were things like CPU temperature monitors which I think
have less value, but I'm imagine we'll see.

> > > i am concerned about abuse of this property by items that will set
>  long
> > > texts: "131 emails". if there is a guarantee to the user of the
> > > StatusNotifierItem API that their text will be shown, then we'll end up
> > > with fairly nasty looking layouts in the system tray. (this will
> > > particularly
> > > 
> > >  look bad with multi-row trays)
> > 
> > Yes multi-row tray can be tricky. The best way to get it to look good
> > would probably be a fluid layout, something like this (ascii art):
> > 
> > +------------+
> > 
> > |@ 100%  @  @|
> > |@  @ 10°    |
> > 
> > +------------+
> 
> i implemented this (or at least something very similar to this) in kicker in
> kde 3.something. it was better, but it still looked pretty bad due to lack
> of alignment. it became a jumble of icons as soon as there was one entry
> that was too wide. at least with the status notifiers, we can enforce that
> all widgets are multiples of some minimum/standard width so that there is
>  some alignment, but the results will still be less than they could be.

Personally, in this case where a grid provides a better layout I think
not showing the labels is an appropriate reaction.  In general, it seems
to me that the label should also be "extra information" so showing it is
handy but not critical to the use of the indicator.  But, I if the text
is desired in the grid layout in that agateau's suggestion is the most
reasonable one.  Basically, try to make the grid as strong as possible.

> > Or a new option could be added to the tray to disable labels (but I
> >
>  dislike adding options)
> > 
> > > one of the problems we've faced in the past with the system tray is app
> > > authors putting all sorts of things that do not particularly belong in
> > > there. they have traditionally abused the system tray for items that
> > > really want to be showing a larger set of information with richer
> > > interaction than can be comfortably accomodated for given what the tray
> > > is required to
> > > 
> > >  support.
> > 
> > True, but the new Label property can also be seen as providing
> > applications a proper way to provide text, to discourage them from
> > abusing the icon by poorly blending text on it.
> 
> it can also be seen as a way to encourage the use of text in a place that
> isn't appropriate. which is exactly what it will do. it's better to make
> undesirable things hard (if possible) than make them easy so that more
>  developers do that.
> 
> that kind of thinking got us into the system tray mess in the first place:
> it was so easy to shove anything in there that that is exactly what people
> did. understandable. a text label will end up encourage the use of text
>  labels.

While I agree with your ideas on API design, I think that we're
providing a set of functionality that is unique with this proposal.
With small icons (panel sized) it's basically impossible to be precise
in the display.  And to overlay text is also non-ideal because making
the text readable requires basically having no icon at all.  So if we
want to provide precise information in a panel visualization, I think
that we really need text to be able to provide that.

		--Ted