Re: New property proposal for StatusNotifierItem protocol: Label
On Friday 13 August 2010 11:11:20 Aurélien Gâteau wrote: On 11/08/2010 14:13, Ivan Čukić wrote: Most likely, we won't use KNotifierStatusItem for KMail's message indicator, but a proper Plasmoid though -- Lion Mail. The email count is currently in a This is a strange decision - what about users that want to use kmail with some other DE? This is what I like about SNI (+Label): it provides a nice cross-desktop way for a separate process (either a standalone application or a separate process desktop tool) to integrate with the desktop. It cannot sensible show me some kind of preview of my new emails though. I mean it could, but then I'd rape the spec. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On 10/08/2010 21:26, Aaron J. Seigo wrote: this could be a similar thing: in this non-standard collection of key/value pairs, Unity (or whatever it really is in this case :) could go looking for an IconText key (or whatever it would get named) and use that. it would mean that there would be no need to expand the spec itself while allowing us to all experiment a bit more freely with it. all without endangering the future quality of the API and burden existing visualizations. and if i am proven horribly, wonderfully wrong and the label text is shown to be a purely awesome idea full of rainbows and unicornsparkles then we could 'promote' that key/value pair into the spec as either a document item in the key/value property, or as a full fledged named property in the API itself what does everyone think? (and by everyone i mean mostly Marco, Ted and Aurelian, though others are welcome to weight in, of course :) (sorry for the latency, I am supposed to be away until Monday) This idea sounds like a reasonable middle ground to me. Ted version is probably even simpler. We can state in the protocol that vendor specific properties can be created, as long as they are named something like XVendorPropertyName. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On 11/08/2010 14:13, Ivan Čukić wrote: Most likely, we won't use KNotifierStatusItem for KMail's message indicator, but a proper Plasmoid though -- Lion Mail. The email count is currently in a This is a strange decision - what about users that want to use kmail with some other DE? This is what I like about SNI (+Label): it provides a nice cross-desktop way for a separate process (either a standalone application or a separate process desktop tool) to integrate with the desktop. Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On 10/08/2010 20:21, Aaron J. Seigo wrote: On August 10, 2010, Ted Gould wrote: * 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 :) passion does not make people right. if we design based on how passionate someone can get about something, everything would be themed after some Japanese cartoon or be based on contet from a Holy Book. sometimes we have to step back and say, I understand your point, but the surrounding issues veto it. Sorry. I think the interesting point of the fact that Apple allows label is not some holy if Apple does it, then we should do it. What's interesting IMHO is that it has been around for a while, and so far I haven't witnessed too much abuse of this label property by third-party Mac OS X developers. I won't pretend to have tried every Mac application out there, of course, but at least the few I have seen extending the menubar this way did it in a reasonable way. You can find some examples of Mac OS X menulets here: http://menu.jeweledplatypus.org/ Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On Friday, August 13, 2010, Aurélien Gâteau wrote: On 11/08/2010 14:13, Ivan Čukić wrote: Most likely, we won't use KNotifierStatusItem for KMail's message indicator, but a proper Plasmoid though -- Lion Mail. The email count is currently in a This is a strange decision - what about users that want to use kmail with some other DE? This is what I like about SNI (+Label): it provides a nice cross-desktop way for a separate process (either a standalone application or a separate process desktop tool) to integrate with the desktop. this steps completely around the question of: do we want applications integration in this way? imho, the answer is no -- 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
Re: New property proposal for StatusNotifierItem protocol: Label
On Friday, August 13, 2010, Aurélien Gâteau wrote: IMHO is that it has been around for a while, and so far I haven't witnessed too much abuse of this label property by third-party Mac OS X the system tray on x11 has a long history of being abused in various ways. to me, that's more relevant than what developers on a different platform have done with a similar desktop component on that platform. -- 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
Re: New property proposal for StatusNotifierItem protocol: Label
On Wednesday 11 August 2010 22:01:24 Aaron J. Seigo wrote: On August 11, 2010, Marco Martin wrote: I think in some cases we could want applet not going away, like lionmail, even if i have kmail closed i could want lionmail continuing to notify me about emails true; in that case the user could just add lion mail themselves, no? (which would supress the addition of another one for the KSNI..) or the KSNI could come from akonadi itself? I like the overall idea, but the above is not very nice as there's suddenly a difference between programmatically added items and manually added ones -- confusing to the user. I'll let your idea sink for a bit, it does sound like a neat idea (though maybe not quite for the Lion Mail usecase). That one is now in the systray just like network and battery. The icon only shows up when there's new email in its configured folder, and empty it's at ~200k in mem consumption, so not that bad. Have a nice weekend, I'm away for a festival until Sunday ... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
Hey Ted, On Tuesday 10 August 2010 20:40:20 Ted Gould wrote: It seems to me that most of them can be handled adequately by adding the label, so implementing or adopting a new API simply more complex than what we need. From my experience (I'm maintaining the battery applet, which has the percentage written on top of it in the system tray area), you're running into a host of problems doing that. Let's have a look: - contrast, depending on the icon theme, text on the icon might be readable, or not - space: At 96dpi (and there aren't many users with less than that out there), you can at most put 3 chars into the standard size of 22px, that's if you want to keep it readable of course. This won't work for weather information, for example. - localisation: While some things might fit in there in the English version, they won't in other localications where the text is often wider, even if it's just a number the local representation often differs (think time, am/pm, percentages can be different, ...) IOW, you have to be really restrictive there when it comes to what to put on there, and then people will still come up with things like scrolling text, or whatever. (Hmm, marquee ... ;) So I've fixed issues on that text on icon display for two years, all those problems went away when we put the text into tooltips, and it was all way more consistent. I suggest you rethink using tooltips, they're really damn useful ;-) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On Tuesday 10 August 2010 19:12:01 Ivan Čukić wrote: The only advantage of this proposal (as far as I'm concerned) is that we could choose how to handle this text providing more consistency, while currently we can't since it is embedded into the icon. Example - battery shows the text on hover, kmail and akregator show it always. The battery does it in the tooltip since 4.5, the new email notifier will do the same. Akregator is a different matter though, as it's not actively developed. I can imagine a solution very similar to the emailnotifier thing I'm working on, making it all more consistent. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
Most likely, we won't use KNotifierStatusItem for KMail's message indicator, but a proper Plasmoid though -- Lion Mail. The email count is currently in a This is a strange decision - what about users that want to use kmail with some other DE? Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On Wednesday 11 August 2010, Sebastian Kügler wrote: So I've fixed issues on that text on icon display for two years, all those problems went away when we put the text into tooltips, and it was all way more consistent. I suggest you rethink using tooltips, they're really damn useful ;-) And even if the constraint is that it must work on touchscreen, sme kind of extra information available only when tapping over the iconcould be necessary, really. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On Wednesday 11 August 2010 14:13:21 Ivan Čukić wrote: Most likely, we won't use KNotifierStatusItem for KMail's message indicator, but a proper Plasmoid though -- Lion Mail. The email count is currently in a This is a strange decision - what about users that want to use kmail with some other DE? I don't know. Maybe the kmail developers keep their old systray code around as a fallback? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On August 11, 2010, Ivan Čukić wrote: Most likely, we won't use KNotifierStatusItem for KMail's message indicator, but a proper Plasmoid though -- Lion Mail. The email count is currently in a This is a strange decision - what about users that want to use kmail with some other DE? i had a really rather nasty idea the other day for these kinds of situations: we could put a key/value entry into KSNI's from our apps that can be serviced by a plasmoid, e.g. Plasmoid = lionmail and when that status notifier appears, the system tray could instead instantiate the right plasmoid if it is installed. beauty of that is: * it's backwards compatible with both xembed and status notifier system trays * it allows the plasmoid to come and go with the app, just as system tray icons do * if the plasmoid isn't installed, it would still Just Work (falling back naturally to the standard status notifier icon) * it would make these apps shine in plasma shells ugly of that is: * it's a hack attached to status notifier :) thoughts? -- 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
Re: New property proposal for StatusNotifierItem protocol: Label
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? 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) 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. 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) 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. -- 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
Re: New property proposal for StatusNotifierItem protocol: Label
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 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. 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. 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) Aurélien ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
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
Re: New property proposal for StatusNotifierItem protocol: Label
On Tuesday 10 August 2010 18:05:30 Aurélien Gâteau wrote: 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. Please don't do that. It get's completely broken as soon as there are translations. I encountered two problems with approaches like only showing part of the text: 1. German tends to need three times the space as English 2. The most important piece of information in a German sentence is the last word. 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
Re: New property proposal for StatusNotifierItem protocol: Label
On Tuesday 10 August 2010, Aurélien Gâteau wrote: 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) not sure on that. i already cringe on the keyboard layout indicator appearance applet because it is text (and i wouldn't know how to make it different here) if random icons had text on them, i think the whole appearance would be really ruined. for things like unread emails, i probably need just an indicator like an overlay icon, and if it's colored, in a monochrome systray would detach itelf enough to serve for the goal i think. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
i already cringe on the keyboard layout indicator appearance applet because it is text (and i wouldn't know how to make it different here) Well, in my case, the keybd indicator without the text is rather useless - the same flag for two different layouts (Latin and Cyrillic). On the other hand, although I find the text rather useful in a few applications, I agree with Aaron that making it too easy for devels, would lead to every icon having some textual info on top of it... The only advantage of this proposal (as far as I'm concerned) is that we could choose how to handle this text providing more consistency, while currently we can't since it is embedded into the icon. Example - battery shows the text on hover, kmail and akregator show it always. Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On Tue, Aug 10, 2010 at 11:12 AM, Ivan Čukić ivan.cu...@gmail.com wrote: i already cringe on the keyboard layout indicator appearance applet because it is text (and i wouldn't know how to make it different here) Well, in my case, the keybd indicator without the text is rather useless - the same flag for two different layouts (Latin and Cyrillic). I have the same problem, both us and us-dvorak have an american flag... On the other hand, although I find the text rather useful in a few applications, I agree with Aaron that making it too easy for devels, would lead to every icon having some textual info on top of it... The only advantage of this proposal (as far as I'm concerned) is that we could choose how to handle this text providing more consistency, while currently we can't since it is embedded into the icon. Example - battery shows the text on hover, kmail and akregator show it always. Cheerio -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
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
Re: New property proposal for StatusNotifierItem protocol: Label
On August 10, 2010, Ivan Čukić wrote: The only advantage of this proposal (as far as I'm concerned) is that we could choose how to handle this text providing more consistency, while currently we can't since it is embedded into the icon. Example - battery shows the text on hover, kmail and akregator show it always. then we just get icons that don't show any useful status. kmail and akregator ought to be adjusted to provide useful information in a less information intensive fashion. keyboard status remains an interesting issue. having it as a plasmoid would be so much nicer in so many ways. but we have the issue of really wanting it always available, but only always available when the service is there. sounds like an interesting use case we don't allow for currently in plasma-desktop (and which may be of interest as well to plasma mobile?) -- 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
Re: New property proposal for StatusNotifierItem protocol: Label
(I just snipped everything else, because I agree this is the heart of the matter) On Tue, 2010-08-10 at 11:21 -0700, Aaron J. Seigo wrote: On August 10, 2010, Ted Gould wrote: 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. and that is the heart of the matter: i don't think we need to, nor want to, try to provide precise information via status notifiers. (there are other more appropriate APIs for that) I think that's were we're coming at this from different positions, we don't have another API for it. Whether we should try and adopt the Plasma Applet API is a discussion for another time, but we simply don't have one right now. So, the question becomes: how do we manage these tasks the user wants to do? It seems to me that most of them can be handled adequately by adding the label, so implementing or adopting a new API simply more complex than what we need. I don't think that the label is ideal, and I agree with many of the issues that you've pointed out. And surely, it will allow application developers who have no taste to exploit the system. But, I think given the choice (from our perspective) of adding a new API or adding a label the label makes more sense. --Ted ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: New property proposal for StatusNotifierItem protocol: Label
On August 10, 2010, Ted Gould wrote: I think that's were we're coming at this from different positions, we don't have another API for it. ah, i see. that is indeed problematic. so i'm guessing this is for Unity or some other not-gnome-panel-based work, meaning you have no pre-existing applet API to lean on. which makes all this make a lot more sense now, assuming i've read that right :) unfortunately, i don't feel comfortable with agreeing to something that would erode the quality of the status notifier API to fill in such a gap (which shouldn't really exist). but perhaps all is not lost! to the important question: have one right now. So, the question becomes: how do we manage these tasks the user wants to do? absolutely... well, here's a suggestion, even though it's not optimal, perhaps: assuming i'm reading between the lines correctly here and this is a Unity related thing where the design goal is to put this kind of information into a screen-edge-docked panel and it needs to be touched-based (which also explains the no-tooltips thing? :) ... ... then these are addons that are created almost exclusively for Unity itself, no? things that you have control over? and things that wouldn't necessarily need to be perfectly rendered in other workspaces? if so ... then perhaps we are back to the issue of: Can we have non-standard key/value pairs as added information that may be implementation specific attached to a StatusNotifierItem. this came up with the audio player menu as well, in terms of how to glue a status notifier from a random player to the mixer popup - that requires jumping from the status notifier from the app to the appropriate MPRIS interface, and that is most reliably done by embedding that information in the status notifier. this could be a similar thing: in this non-standard collection of key/value pairs, Unity (or whatever it really is in this case :) could go looking for an IconText key (or whatever it would get named) and use that. it would mean that there would be no need to expand the spec itself while allowing us to all experiment a bit more freely with it. all without endangering the future quality of the API and burden existing visualizations. and if i am proven horribly, wonderfully wrong and the label text is shown to be a purely awesome idea full of rainbows and unicornsparkles then we could 'promote' that key/value pair into the spec as either a document item in the key/value property, or as a full fledged named property in the API itself what does everyone think? (and by everyone i mean mostly Marco, Ted and Aurelian, though others are welcome to weight in, of course :) -- 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
Re: New property proposal for StatusNotifierItem protocol: Label
On Tue, 2010-08-10 at 12:26 -0700, Aaron J. Seigo wrote: On August 10, 2010, Ted Gould wrote: I think that's were we're coming at this from different positions, we don't have another API for it. ah, i see. that is indeed problematic. so i'm guessing this is for Unity or some other not-gnome-panel-based work, meaning you have no pre-existing applet API to lean on. which makes all this make a lot more sense now, assuming i've read that right :) Yes, it is. Also, the gnome-panel API is also deprecated so developers are being discouraged from using it as well. Nothing has been defined for GNOME Shell to fill this gap as far as I know[1]. And Unity doesn't have an API for extension like this other than KSNI currently. Can we have non-standard key/value pairs as added information that may be implementation specific attached to a StatusNotifierItem. snip this could be a similar thing: in this non-standard collection of key/value pairs, Unity (or whatever it really is in this case :) could go looking for an IconText key (or whatever it would get named) and use that. It seems to me that it'd make more sense to just have Dbus properties in the X namespace rather than a special method for looking up a different set of key/values. So we'd have a property like XAyatanaLabel which we'd use, and once you realize the ground unicorn that we've added it could be adjusted to just Label. --Ted [1] Well, besides writing JS right in GNOME Shell, but that's not really an API. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
