New property proposal for StatusNotifierItem protocol: Label

Aaron J. Seigo aseigo at kde.org
Tue Aug 10 18:40:54 CEST 2010


On August 10, 2010, Aurélien Gâteau wrote:
> > i think it's only really useful if there is a reliable way to show the
> > text. placing it next to the iconic representation is probably the only
> > way to do this reliably given that icons can be very small and it's
> > nearly impossible to tell where it is appropriate to overlay text onto a
> > random icon without
> > 
> >  knowing something about its visual contents. is that what you are
> >  planning?
> 
> Yes, as far as I know.

ok, so ... the information density of the system tray / notifications area
is pretty high. adding text to it is not a good direction, imho. those
things that require text (and i believe them to be exceptionally few) can be
 implemented in other ways.

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.

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

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

> > looking at the use cases provided, is there really a need for such
> >
 
> >  text?
> > 
> > for plasma, the battery is a proper plugin / applet. (and even then, by
> > default it doesn't show text in the tray.) for the rest of the entries,
> > we rely on graphical cues for status change and the tooltips to
> > communicate details. is it important to see that you have 1045 emails at
> > all times in the system tray? i also wonder how an email client would
> > give a useful
> > 
> >  LabelGuide (i suppose it wouldn't)
> 
> This is up to the application to decide. KMail can already show this
> message count.

that doesn't mean it's a good idea :)

> I agree for you and me this
 information has little value.
> It is very different for people who receive 2 or 3 mails a day.

the idea is that if you have 1 email now and then later you have 2 emails,
you will go and check them? i can see the logic, but i don't think i agree
that it's a worthwhile use case. it's not something that extends to 100s (or
probably even dozens) of emails very well, and in the case of 100+ emails
it's going to be hard to make it look good. which means it will be a feature
that is broken for many people with no good answer as to how to fix it.
 "building in bugs" is a bad idea.

and if we remove that as a possibility, perhaps email app devs will get
creative and find better solutions. like using icon status / colours to
denote different states: new email has arrived recently, you have existing
unead mail but nothing very new, you have no unread mail. do i really need
 text to say that?

> As for setting a LabelGuide for this use. I think in this case it would
>
 be fine to let the host adjusts dynamically.

yes, i agree that would be required.

> > the keyboard layout indicator is
 probably the best / most defensible use
> > case provided. i wonder if that also doesn't belong as a proper applet
 in
> > 
> >  the panel, though.
> > 
> > i'm not 100% opposed to the idea if there are hard use cases that simply
> > can't be done without it, but i think there are a number of caveats and
 i
> > am quite confident that we'll end up with situations where the results
> > are
> > 
> >  visually poor.
> > 
> > back in gnome 1.x and early gnome 2.x days there was a system tray icon
> > for showing network traffic that would place an icon and a label in the
> > x window that would get embedded. it's the kind of things people do when
> > you give them the flexibility to do so. when designing these things, we
> > need to think not only of how we will use them in our own goodies, but
> > how 3rd parties are
> > 
> >  going to use them and what our commitments become given the API we
> >  offer.
> 
> I would say we have much more control now with the SNI protocol. We can
> limit things to sane values. For example the host could decide on a
> maximum width and simply fade out the text if it's too wide. A useful

how wide is too wide? where is the important information in the label?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100810/8dae6c64/attachment.sig 


More information about the Plasma-devel mailing list