New property proposal for StatusNotifierItem protocol: Label
aurelien.gateau at canonical.com
Tue Aug 10 18:05:30 CEST 2010
On 10/08/2010 16:46, Aaron J. Seigo wrote:
> On August 10, 2010, Aurélien Gâteau wrote:
>> I think this would give more flexibility and I can see a use for this
>> new property in a few KDE applications, KMail and Choqok for example
>> could use it to show the message count, the keyboard layout indicator
>> could use it as well.
>> What do you think?
> 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.
> 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° |
(@ are supposed to be icons)
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
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.
> looking at the use cases provided, is there really a need for such
> 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. 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.
As for setting a LabelGuide for this use. I think in this case it would
be fine to let the host adjusts dynamically.
> 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
recommendation in this sense would be to ask application developers to
repeat the information in the tooltip so that one can ensure the text is
always available (would be useful if a "no label" option is added)
More information about the Plasma-devel