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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
