Re: VDG suggestions and wishes about the system tray
On Thursday 25 September 2014 16:05:29 David Edmundson wrote: > I'd like to think maybe this shows we can give it another chance. Projects > and the surrounding social situations do change over time. Plus having > commit access makes it all so much easier. > > David yay :D -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
Status Notifier Item is now listed under "used by one or more desktop", the same level as the icon naming spec. \o/ > (and i don't think at this point any new meaningful work can happen on > freedesktop at all) I'd like to think maybe this shows we can give it another chance. Projects and the surrounding social situations do change over time. Plus having commit access makes it all so much easier. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Monday 01 September 2014, David Edmundson wrote: > > final specification won't happen, at least not on freedesktop (and i > > don't think at this point any new meaningful work can happen on > > freedesktop at all) > > Any objections to me trying? oh no, if you manage to get this going again would be uber awesome > I already have fd.o wiki access (I'm so important!) so I can at least > copy your website contents into the main place, we're listed under in > drafts so I can do that without discussion on their ML and it will > make it look way more "official" than it does now. I'm not 100% sure the one on freedestkop wiki is the updated version, but there was a copy in the wiki www.freedesktop.org/wiki/Specifications/StatusNotifierIcon/ can't check atm, several freedesktop sites like wiki and its git looks to be down for me today > Then we can fire off a request to move it from "Planning" to somewhere > better. +1 -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 01.09.2014 12:57, David Edmundson wrote: On Mon, Sep 1, 2014 at 9:46 AM, Marco Martin wrote: On Sunday 31 August 2014, Thomas Pfeiffer wrote: That said, I'm not against trying it. I think the first step towards that would be finishing a proper cross-desktop specification so that it's clear what we want encourage people to do. See my mail "State of the StatusNotifierIcon spec and implementation". having a proper specification was blocked at the time by gnome, and all attepts to resurrect the process was met with as many roadblocks. with ubuntu, at least has been reached an agreement, not identical but at least applications do work on one another, and given the state of things, this is already amazing. final specification won't happen, at least not on freedesktop (and i don't think at this point any new meaningful work can happen on freedesktop at all) Any objections to me trying? I already have fd.o wiki access (I'm so important!) so I can at least copy your website contents into the main place, we're listed under in drafts so I can do that without discussion on their ML and it will make it look way more "official" than it does now. Then we can fire off a request to move it from "Planning" to somewhere better. +1 from me! I've learned now that fd.o isn't really functional anymore at this point, but unless a functioning alternative body has been established, we should try what we can there. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Mon, Sep 1, 2014 at 9:46 AM, Marco Martin wrote: > On Sunday 31 August 2014, Thomas Pfeiffer wrote: >> > >> > That said, I'm not against trying it. >> >> I think the first step towards that would be finishing a proper >> cross-desktop specification so that it's clear what we want encourage >> people to do. See my mail "State of the StatusNotifierIcon spec and >> implementation". > > having a proper specification was blocked at the time by gnome, and all > attepts to resurrect the process was met with as many roadblocks. > with ubuntu, at least has been reached an agreement, not identical but at > least applications do work on one another, and given the state of things, this > is already amazing. > > final specification won't happen, at least not on freedesktop (and i don't > think at this point any new meaningful work can happen on freedesktop at all) Any objections to me trying? I already have fd.o wiki access (I'm so important!) so I can at least copy your website contents into the main place, we're listed under in drafts so I can do that without discussion on their ML and it will make it look way more "official" than it does now. Then we can fire off a request to move it from "Planning" to somewhere better. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Saturday 30 August 2014, Eike Hein wrote: > On 30.08.2014 14:31, Thomas Pfeiffer wrote: > > I just looked up the draft specification (since there is no final one > > yet) from our side [1] and looky what I found: > > > > "Passive: The item doesn't convey important information to the user, it > > can be considered an "idle" status and is likely that visualizations > > will chose to hide it." > > > > Yes, that doesn't say that Plasma will definitely hide passive SNIs, but > > according to this specification, developers should actually _expect_ > > visualizations to hide passive SNIs. So, according to this > > specification, applications that rely on passive SNIs _not_ to be hidden > > are clearly doing it wrong, and we could hit them over the head with the > > spec if they complain. > > I disagree with this premise. The spec is simply vague. "Hiding" > can mean "remove from field of view". Something hidden generally > still exists, and can be reached somehow. This is in fact the > meaning of "hidden" in our current UI (not just in the tray, btw. > - think of panel auto-hide). It's worth pointing out that the > designers of that UI contributed to the spec you're talking about. a bit of explanation of why the spec was done this way. Its premise is exactly to say as less as possible on how the thing should *look*, it's merely a description of a model with at most some suggestion on the implementation. exactly for the reason that some day, we would have wanted to make it look slightly different, like, now. now the problem, rather than just of what visual representation, is more functional: if the item is completely hidden, I lose completely the possibility to get back to its window. This is a problem explicitly of applications that use the systray as a mini taskbar, that's kinda evil but's that's how it is.. but wait this is just a subset, and we have data for that, the items do say if they are "application", "system" "network control" what I suggest is the following heuristic, done expressely to work in the maximum amount of use cases * hide passive statusnotifiers when are *not* of type "application" (so like ktorrent, konversation, kmail would stay there regardless, some "system" utility would hide) * for plasmoids, add a new state, so permits to do a more fine grained control, and would be responsibility of the plasmoid to actually show and hide itself, because only plasmoids are controlled enough to be "trustable" enough to do the right thing. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Sunday 31 August 2014, Thomas Pfeiffer wrote: > > > > That said, I'm not against trying it. > > I think the first step towards that would be finishing a proper > cross-desktop specification so that it's clear what we want encourage > people to do. See my mail "State of the StatusNotifierIcon spec and > implementation". having a proper specification was blocked at the time by gnome, and all attepts to resurrect the process was met with as many roadblocks. with ubuntu, at least has been reached an agreement, not identical but at least applications do work on one another, and given the state of things, this is already amazing. final specification won't happen, at least not on freedesktop (and i don't think at this point any new meaningful work can happen on freedesktop at all) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Sunday 31 August 2014 13:17:34 Sebastian Kügler wrote: > On Saturday, August 30, 2014 14:31:16 Thomas Pfeiffer wrote: > > Yes, that doesn't say that Plasma will definitely hide passive SNIs, but > > according to this specification, developers should actually _expect_ > > visualizations to hide passive SNIs. So, according to this specification, > > applications that rely on passive SNIs _not_ to be hidden are clearly > > doing > > it wrong, and we could hit them over the head with the spec if they > > complain. > > > > [1] http://www.notmart.org/misc/statusnotifieritem/statusnotifieritem.html > > Note that from my experience, it doesn't work like that. Application authors > won't complain, giving an opportunity to "hit them over the head with the > spec", they'll just abuse the implementation to get the behaviour as close > to what they imagine to be good (whether it is good or not is a different > story entirely). This is not "wrong or right" thing, it's a matter of > encouraging the right behaviour (and offering something desirable in the > first place). > > That said, I'm not against trying it. I think the first step towards that would be finishing a proper cross-desktop specification so that it's clear what we want encourage people to do. See my mail "State of the StatusNotifierIcon spec and implementation". ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Saturday, August 30, 2014 14:31:16 Thomas Pfeiffer wrote: > Yes, that doesn't say that Plasma will definitely hide passive SNIs, but > according to this specification, developers should actually _expect_ > visualizations to hide passive SNIs. So, according to this specification, > applications that rely on passive SNIs _not_ to be hidden are clearly doing > it wrong, and we could hit them over the head with the spec if they > complain. > > [1] http://www.notmart.org/misc/statusnotifieritem/statusnotifieritem.html Note that from my experience, it doesn't work like that. Application authors won't complain, giving an opportunity to "hit them over the head with the spec", they'll just abuse the implementation to get the behaviour as close to what they imagine to be good (whether it is good or not is a different story entirely). This is not "wrong or right" thing, it's a matter of encouraging the right behaviour (and offering something desirable in the first place). That said, I'm not against trying it. -- 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: VDG suggestions and wishes about the system tray
On 30.08.2014 14:31, Thomas Pfeiffer wrote: I just looked up the draft specification (since there is no final one yet) from our side [1] and looky what I found: "Passive: The item doesn't convey important information to the user, it can be considered an "idle" status and is likely that visualizations will chose to hide it." Yes, that doesn't say that Plasma will definitely hide passive SNIs, but according to this specification, developers should actually _expect_ visualizations to hide passive SNIs. So, according to this specification, applications that rely on passive SNIs _not_ to be hidden are clearly doing it wrong, and we could hit them over the head with the spec if they complain. I disagree with this premise. The spec is simply vague. "Hiding" can mean "remove from field of view". Something hidden generally still exists, and can be reached somehow. This is in fact the meaning of "hidden" in our current UI (not just in the tray, btw. - think of panel auto-hide). It's worth pointing out that the designers of that UI contributed to the spec you're talking about. It's also possible for the spec to be wrong. It's a draft. And again, if apps like that are inherently "doing it wrong", then it's not their fault because our libraries and our desktop shell UI doesn't support writing and using applications in this way very well. If I see you "hit application devs over the head" based on such poorly-argued arguments I won't be impressed, and nor, presuma- bly, will they. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:14:28 Sebastian Kügler wrote: > On Thursday, August 28, 2014 12:08:04 Martin Klapetek wrote: > > On Thu, Aug 28, 2014 at 12:02 PM, Sebastian Kügler wrote: > > > > On Tuesday, August 26, 2014 22:00:54 Eike Hein wrote: > > > Hiding "passive" status notifier items robs the user of an > > > entire tier of organization when deciding how near/far they > > > want to place a running app. > > > > This may also encourage more abuse: i.e. not setting the status to hidden, > > ever. Remember that we're often dealing with apps who want to forego being > > shown in the taskbar (presumably to save space). Effectively, this means > > that apps will set their status to always be active, leading to more > > clutter in the panel. > > > > On the other hand, it's how Unity (and maybe others?) work for years. > > Let's > > find out if it was a real problem for them and about how many apps are > > they > > aware of abusing this? > > Ah, yes, thought about that, too. > > I agree that it could be tried, but I wouldn't be surprised if for Plasma, > we come to a different conclusion. There's a certain difference in the > "audiences" between Unity and Plasma, and that might very well manifest > itself in apps having problems with this behaviour in Plasma (those that > don't care about Unity). On the other hand, more consistent behaviour > between statusnotifier implementations is probably a good thing. I just looked up the draft specification (since there is no final one yet) from our side [1] and looky what I found: "Passive: The item doesn't convey important information to the user, it can be considered an "idle" status and is likely that visualizations will chose to hide it." Yes, that doesn't say that Plasma will definitely hide passive SNIs, but according to this specification, developers should actually _expect_ visualizations to hide passive SNIs. So, according to this specification, applications that rely on passive SNIs _not_ to be hidden are clearly doing it wrong, and we could hit them over the head with the spec if they complain. [1] http://www.notmart.org/misc/statusnotifieritem/statusnotifieritem.html ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:14:28 Sebastian Kügler wrote: > I agree that it could be tried, but I wouldn't be surprised if for Plasma, > we come to a different conclusion. There's a certain difference in the > "audiences" between Unity and Plasma Is there? I don't really know what is our audience, even less what is theirs. I honestly thought we were competing for more or less the same audience, at least I am. 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: VDG suggestions and wishes about the system tray
On Thursday, August 28, 2014 19:54:53 David Edmundson wrote: > > For this case, to allow to configure this basic functionality we came up > > with greying them out if the plasmoid is not configured to show > > non-removable devices. This way it's clear that it currently does not hold > > any information, however the configuration dialogue is still available. > > The icons are monochrome already? You can't grey them out further We can reduce the opacity, which is what we're doing in other cases as well, when there's no suitable highlight. -- 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: VDG suggestions and wishes about the system tray
> > For this case, to allow to configure this basic functionality we came up > with greying them out if the plasmoid is not configured to show > non-removable devices. This way it's clear that it currently does not hold > any information, however the configuration dialogue is still available. The icons are monochrome already? You can't grey them out further ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 28.08.2014 17:52, Marco Martin wrote: On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: Hello everyone, the VDG told me to take a look at the system tray after the 5.0 releases, because even though it's a huge step forward, we felt that there are some inconsistencies in how it behaves. My task was to identify these issues and come up with possible solutions. We talked about them already and think it is now time to come forwards with our suggestions. If these ideas are accepted we'll deliver guidelines on how to integrate an application nicely into the system tray. so ,as a conclusion, I want to try to do a very bare bone recap: * there seems to be too many icons in the popup, especially some that don't really do much * completely hiding icons of statusnotifiers of applications gives problems, because makes those applications unreachable for all intents and purposes * however should be pretty safe to hide plasmoids: with a possible state more, things like the device notifier can be completely hidden when empty * an extra state for statusnotifiers may cause problems for unity and the two gtk clients. * completely hide vs an extra layer of show/collapse what's better? * As a first action item, completely hide really empty plasmoids (it would be up to the plasmoid logic to decide that with setting the proper state on itself) * Still open problem: less crowded popup, but still being able to access applications that are accessible only by their systray icon I'd also add that Unity's and Plasma's interpretation of the spec are currently not compatible. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 28.08.2014 14:32, Sebastian Kügler wrote: On Thursday, August 28, 2014 13:38:49 Marco Martin wrote: it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) one thing i would love, is to expand what we are doing with dbus activation of plasmoids, even tough for things like "not having any removable storage device attached" would require some more complex rules I'd think that dbus-activated plasmoids don't need this, since they come and go already (makes them essentially hidden). For the devicenotifier, it has to stay, since it could be configured to show non-removable devices as well, so the logic currently in there is fine, and we can rely on the status. For this case, to allow to configure this basic functionality we came up with greying them out if the plasmoid is not configured to show non-removable devices. This way it's clear that it currently does not hold any information, however the configuration dialogue is still available. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 19:06:45 David Edmundson wrote: > > I don't understand why we would have an extra state. > > If one wants to completely hide a status notifier, don't create a > status notifier in the first place. yes, if an application doesn't need it and is visible, it should just not create/delete it however if the main window is hidden already and is accessible only via statusnotifieritem, it shouldn't delete it, again from the thread discussion, there is the unfortunately common case of applications that use them as little taskbar entry replacement -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thu, Aug 28, 2014 at 5:52 PM, Marco Martin wrote: > On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: >> Hello everyone, >> >> the VDG told me to take a look at the system tray after the 5.0 >> releases, because even though it's a huge step forward, we felt that >> there are some inconsistencies in how it behaves. My task was to >> identify these issues and come up with possible solutions. We talked >> about them already and think it is now time to come forwards with our >> suggestions. If these ideas are accepted we'll deliver guidelines on how >> to integrate an application nicely into the system tray. >> > > so ,as a conclusion, I want to try to do a very bare bone recap: Thanks for doing that. > * there seems to be too many icons in the popup, especially some that don't > really do much > * completely hiding icons of statusnotifiers of applications gives problems, > because makes those applications unreachable for all intents and purposes > * however should be pretty safe to hide plasmoids: with a possible state more, > things like the device notifier can be completely hidden when empty > * an extra state for statusnotifiers may cause problems for unity and the two > gtk clients. I don't understand why we would have an extra state. If one wants to completely hide a status notifier, don't create a status notifier in the first place. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
> yeah, the function to check from the scripting engine is there and ported, > but > the systray doesn't use it and just adds it by default, i guess because there > are brightness controls as well now And the PM checkbox which is handy on desktop too. And it shows your mouse battery, if any. So battery should he added all the time, passive if no batteries. (Which is what it does atm) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 18:09:49 Ivan Čukić wrote: > > I think for batteries, we're doing that already (at least in Plasma 4 we > > didn't add the battery plasmoid to the panel for desktop systems). > > It does not work for me. Source install on the desktop system, but I do have > the battery indicator. yeah, the function to check from the scripting engine is there and ported, but the systray doesn't use it and just adds it by default, i guess because there are brightness controls as well now -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
> I think for batteries, we're doing that already (at least in Plasma 4 we > didn't add the battery plasmoid to the panel for desktop systems). It does not work for me. Source install on the desktop system, but I do have the battery indicator. Cheerio ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Tuesday 26 August 2014 21:26:42 Philipp Stefan wrote: > Hello everyone, > > the VDG told me to take a look at the system tray after the 5.0 > releases, because even though it's a huge step forward, we felt that > there are some inconsistencies in how it behaves. My task was to > identify these issues and come up with possible solutions. We talked > about them already and think it is now time to come forwards with our > suggestions. If these ideas are accepted we'll deliver guidelines on how > to integrate an application nicely into the system tray. > so ,as a conclusion, I want to try to do a very bare bone recap: * there seems to be too many icons in the popup, especially some that don't really do much * completely hiding icons of statusnotifiers of applications gives problems, because makes those applications unreachable for all intents and purposes * however should be pretty safe to hide plasmoids: with a possible state more, things like the device notifier can be completely hidden when empty * an extra state for statusnotifiers may cause problems for unity and the two gtk clients. * completely hide vs an extra layer of show/collapse what's better? * As a first action item, completely hide really empty plasmoids (it would be up to the plasmoid logic to decide that with setting the proper state on itself) * Still open problem: less crowded popup, but still being able to access applications that are accessible only by their systray icon -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 14:32:38 Sebastian Kügler wrote: > I'd think that dbus-activated plasmoids don't need this, since they come and > go already (makes them essentially hidden). > > For the devicenotifier, it has to stay, since it could be configured to show > non-removable devices as well, so the logic currently in there is fine, and > we can rely on the status. for plasmoids we can safely add an additional status, (as opposed to kstatusnotifieritems where i don't feel it can be added safely and still play nice with other implementations) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday, August 28, 2014 13:38:49 Marco Martin wrote: > > > it is a really a bad thing to have so many empty panels in - no > > > devices, > > > no notifications, no batteries etc. > > > > I think for batteries, we're doing that already (at least in Plasma 4 we > > didn't add the battery plasmoid to the panel for desktop systems). > > > > For notifications and storage devices, I quite like the idea. Maybe worth > > a > > try to hide them completely and gauge the user reaction? (I can imagine > > nobody would miss it.) > > one thing i would love, is to expand what we are doing with dbus activation > of plasmoids, even tough for things like "not having any removable storage > device attached" would require some more complex rules I'd think that dbus-activated plasmoids don't need this, since they come and go already (makes them essentially hidden). For the devicenotifier, it has to stay, since it could be configured to show non-removable devices as well, so the logic currently in there is fine, and we can rely on the status. -- 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: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:02:04 Sebastian Kügler wrote: > On Wednesday, August 27, 2014 10:12:54 Ivan Čukić wrote: > > I'm not going to chime in regarding the applications - I tend to agree > > with > > both parties - that not everything needs to be shown, yet that people like > > some of their applications minimized to tray (myself included - I even > > hide > > those applications from the task bar). > > > > One thing where I fully support the proposal is for plasmoids in the tray > > - > > it is a really a bad thing to have so many empty panels in - no devices, > > no notifications, no batteries etc. > > I think for batteries, we're doing that already (at least in Plasma 4 we > didn't add the battery plasmoid to the panel for desktop systems). > > For notifications and storage devices, I quite like the idea. Maybe worth a > try to hide them completely and gauge the user reaction? (I can imagine > nobody would miss it.) one thing i would love, is to expand what we are doing with dbus activation of plasmoids, even tough for things like "not having any removable storage device attached" would require some more complex rules -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
[I'm obviously on the list, CC:ing breaks threading and filtering for me] On Thursday, August 28, 2014 12:29:19 Kai Uwe Broulik wrote: > > I think for batteries, we're doing that already (at least in Plasma 4 we > > didn't add the battery plasmoid to the panel for desktop systems). > > I am not sure whether distributions with their custom layout.js picked that > up (I'm not even sure if I changed that in our default layout) but battery > monitor is supposed to be added to the panel regardless since 4.11. It > provides the handy PM switch and shows peripheral device batteries too. > > However, battery monitor goes passive when: > - The AC is plugged in and the battery is fully charged (since 4.8 or so > already) - There are no power supply batteries (desktop case, if you want > to have it present nonetheless you can force it active) For the battery, it's (for now) not an option to completely remove it. I'd like to change my keyboard backlight whenever I want. -- 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: VDG suggestions and wishes about the system tray
Hi, > I think for batteries, we're doing that already (at least in Plasma 4 we > didn't add the battery plasmoid to the panel for desktop systems). I am not sure whether distributions with their custom layout.js picked that up (I'm not even sure if I changed that in our default layout) but battery monitor is supposed to be added to the panel regardless since 4.11. It provides the handy PM switch and shows peripheral device batteries too. However, battery monitor goes passive when: - The AC is plugged in and the battery is fully charged (since 4.8 or so already) - There are no power supply batteries (desktop case, if you want to have it present nonetheless you can force it active) Cheers, Kai Uwe > For notifications and storage devices, I quite like the idea +1 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday 28 August 2014 12:02:04 Sebastian Kügler wrote: > For notifications and storage devices, I quite like the idea. Maybe worth a > try to hide them completely and gauge the user reaction? (I can imagine > nobody would miss it.) +1. If people just want to access the configuration for them, they can go via System Settings. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Thursday, August 28, 2014 12:08:04 Martin Klapetek wrote: > On Thu, Aug 28, 2014 at 12:02 PM, Sebastian Kügler wrote: > > On Tuesday, August 26, 2014 22:00:54 Eike Hein wrote: > > Hiding "passive" status notifier items robs the user of an > > entire tier of organization when deciding how near/far they > > want to place a running app. > > This may also encourage more abuse: i.e. not setting the status to hidden, > ever. Remember that we're often dealing with apps who want to forego being > shown in the taskbar (presumably to save space). Effectively, this means > that apps will set their status to always be active, leading to more > clutter in the panel. > > On the other hand, it's how Unity (and maybe others?) work for years. Let's > find out if it was a real problem for them and about how many apps are they > aware of abusing this? Ah, yes, thought about that, too. I agree that it could be tried, but I wouldn't be surprised if for Plasma, we come to a different conclusion. There's a certain difference in the "audiences" between Unity and Plasma, and that might very well manifest itself in apps having problems with this behaviour in Plasma (those that don't care about Unity). On the other hand, more consistent behaviour between statusnotifier implementations is probably a good thing. -- 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: VDG suggestions and wishes about the system tray
On Thu, Aug 28, 2014 at 12:02 PM, Sebastian Kügler wrote: > On Tuesday, August 26, 2014 22:00:54 Eike Hein wrote: > > Hiding "passive" status notifier items robs the user of an > > entire tier of organization when deciding how near/far they > > want to place a running app. > > This may also encourage more abuse: i.e. not setting the status to hidden, > ever. Remember that we're often dealing with apps who want to forego being > shown in the taskbar (presumably to save space). Effectively, this means > that > apps will set their status to always be active, leading to more clutter in > the > panel. > On the other hand, it's how Unity (and maybe others?) work for years. Let's find out if it was a real problem for them and about how many apps are they aware of abusing this? Cheers -- Martin Klapetek | KDE Developer ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Wednesday, August 27, 2014 10:12:54 Ivan Čukić wrote: > I'm not going to chime in regarding the applications - I tend to agree with > both parties - that not everything needs to be shown, yet that people like > some of their applications minimized to tray (myself included - I even hide > those applications from the task bar). > > One thing where I fully support the proposal is for plasmoids in the tray - > it is a really a bad thing to have so many empty panels in - no devices, > no notifications, no batteries etc. I think for batteries, we're doing that already (at least in Plasma 4 we didn't add the battery plasmoid to the panel for desktop systems). For notifications and storage devices, I quite like the idea. Maybe worth a try to hide them completely and gauge the user reaction? (I can imagine nobody would miss it.) -- 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: VDG suggestions and wishes about the system tray
On Tuesday, August 26, 2014 22:00:54 Eike Hein wrote: > Hiding "passive" status notifier items robs the user of an > entire tier of organization when deciding how near/far they > want to place a running app. This may also encourage more abuse: i.e. not setting the status to hidden, ever. Remember that we're often dealing with apps who want to forego being shown in the taskbar (presumably to save space). Effectively, this means that apps will set their status to always be active, leading to more clutter in the panel. -- 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: VDG suggestions and wishes about the system tray
On Tuesday, August 26, 2014 22:35:01 Philipp Stefan wrote: > In case of music players and similar, we feel like these applications > should not provide their own status notifiers. E.g. a music player > should be controlled via their mpris2 interface, which can be accessed > by a separate plasmoid in the system tray. > If the status notifiers are used like we intend them to, then the > "passive" status really does not provide any benefit for the user any > more. For example, if a music player idles, because the playlist has > ended, then there's no difference between closing the window and > reviving it again with the status notifier, or closing it and opening it > again with KRunner, kickoff etc. In reality, app developers will want to do something more rich, and then mpris is suddenly not good enough. Also, restarting the app to bring its window to the front only works for unique apps (apps with only one instance), and is completely different from what users are used to. (I do think it's logical, and even Android does it this way without the world having ended yet, but it's not typical behaviour for desktop apps, where there's a distinct difference between apps running and apps not running (even if this difference is an implementation detail) -- Eike already explained that as "application lifecycle". -- 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: VDG suggestions and wishes about the system tray
I think I should maybe clarify a few things here as I feel that my original post has left behind the idea in some that we sought a solution in search for a problem. So what is the problem we are trying to solve? The problem is that currently the system tray icons behave unpredictable to the user or formulated differently: The user can not predict the status of an application based on where its icon shows up in the system tray, so the burden of differentiating and rating if an application provides important information lays on the user instead of the application/application developer. This problem exists to some extent in the panel part of the system tray, but it is most apparent in the popup. In the popup we have plasmoids which hold no information for the user except when they do, like the battery plasmoid when the battery is fully charged but is still used to adjust the monitor brightness. The same thing can be said about status notifiers. So the popup loses its function as an area for information that is still somewhat relevant to the user, but not relevant enough to warrant constant display, because the actual important parts are buried beneath a flood of icons/notifiers with no relevant information at all. The idea of this area is sound, but it does not work with the tool at hand. The very best solution would be to add a 4th state to SNI, a "needsHiding" state, if you will. However, we share this specification with another DE, Unity. So there are several possibilities how things could play out: 1. Canonical accepts the changes and changes their system tray to accommodate the new behaviour. All applications using status notifiers would have to be adapted. This would also solve the issue that some KDE applications' notifier is broken in Unity e.g. KTorrent. I'm not sure how realistic this option is, given that they seem very happy with how their implementation works. 2. We adopt Unity's policy in handling the "passive" status. Only some applications like KTorrent would have to be adapted, but would now be working in both Plasma and Unity again. 3. We add a 4th status to SNI without Canonical's agreement. We'd end up with xembed, GNOME Shell's thing, appindicators, and our new SNI – 4 with each other incompatible solutions. The only place where we can realistically pull this off is system tray plasmoids, as they would not work in Unity anyway to my information. 4. Do nothing, the system tray popup remains as cluttered and space wasting as always. Another thing to clarify: The proposal of the changes on plasmoids and status notifiers are _not_ independent of each other. If the changes to plasmoids are accepted, then we would have improved the their usefulness, but the overall problem would still be there. We need to have a way to separate the useful "passive" icons from the useless in order to improve the situation. We think that the most realistic option is 2., but the best solution would of course be 1. I have tried to reach out to Canonical, but I had not much luck, probably because I do not know the right people. What's important to note is that we really did not came up with this out of the blue, and we did assess the situation, what applications are doing and why. We really just want to improve the situation and think that 2. is the most realistic option while encompassing relatively little work. We don't like to break work flows either. If we can pull of 1. that would be rad, but I really doubt it's going to happen any time soon. Cheers Phil ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 27.08.2014 15:32, Eike Hein wrote: 1 = Pages 6 & 7 of http://arstechnica.com/apple/2011/07/mac-os-x-10-7/7/ are a good read. Sorry - I meant 7 & 8. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 27.08.2014 06:02, Philipp Stefan wrote: Hmm, could you give me some examples for applications with status notifiers that handles this that way? I mean, sure applications like Inkscape and LibreOffice won't start up in the same state like when they were closed, however, applications like them don't seem to use status notifiers. I found that mostly media centred applications and those that provide background functionality like update notifiers seem to use status notifiers. Most of the ones I saw had a way or another to realize a state that is consistent with when you close the application. The only difference was startup time, but that's another story. I see your concern though. A lot of the time state is subtle things like: The tab you last raised, the UI element that has keyboard focus, the scroll position of a list view, ... there's a lot of things apps don't remember because developer side it's opt-in, you need to explicitly wire a lot of this up without that much support from the libraries. That's what I meant with the platform angle on the topic of application lifecycle - mobile platforms often implement a "the system reserves the right to kill the application at any time" model because of resource constraints and avail- ability guarantees. That means they had to give applications the support to cope with this, and train developers to be aware of the concerns. As a by-product apps on these plat- forms often no longer have an explicit "it's running" state in the UI, nor an explicit Quit action (but you also see a lot of apps that don't fit this idea well and end up fighting the system to stay alive). OS X is the primary desktop operating system that has attempted to bring this model to the desktop so far, with OS X 10.7 in 2011 introducing significant new APIs and changes for the process model and the document model[1]. A lot of that ended up getting rolled back in 10.8 (some of it even in point releases) because it didn't work well in practice. So it's not easy. 1 = Pages 6 & 7 of http://arstechnica.com/apple/2011/07/mac-os-x-10-7/7/ are a good read. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 27.08.2014 10:16, Philipp Stefan wrote: One question remains though, why do users not want KTorrent to take up 22px, but are okay with an indicator for the music player while having the music control plasmoid active too. Just a brief note: I'm not - I disable the media control plasmoid because it's redundant with the Cantata icon. No doubt you'll find user systems with both running, though, because enabling the plas- moid by default wasn't their choice and they don't know how to turn it off (or don't care enough). The "I put it where I want it" tends to only happen in connection to stuff that the user con- sciously conjured up, I think. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Wednesday 27 August 2014, Martin Gräßlin wrote: > My personal suggestion (which won't surprise anyone on this list) is to > move the application status notifiers into the tasks applet. But that's > not a really easy task and would not interact well with the remaining > tasks. From my experience it's obvious that users don't want their > ktorrent to take up any useable space from other applications, but it > needs to be easily reachable when they want to interact with it. the idea back in the day was to have the items of categoration "applicationstatus" in the taskbar, and the hardware status/network etc still in the systray. but there were never a design solution that actually worked, since it poses the exact same problems that are in the systray right now -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On Wednesday 27 August 2014, k...@privat.broulik.de wrote: > don't have players > sit in the tray approach), "Active state" > - KMail 149 unread mails, "Active state" > - KTP online, "Active state" > - KMix, 50% volume, "Active state" > > None of them have the "NeedsAttentionStatus" yet still they're all > useful (except > maybe Amarok) yeah, it's a behavioral change of an api, not sure if it would work that well another way may be adding a new value, but would break kde applications in unity -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
Hi, If your application has finished its job like e.g. an update notifier but should continue to run in the background, then use the "passive" flag. If you want to misuse the system tray as second task bar, then do not use the passive flag, but let it remain active. And if your application has finished its job and should not continue to run in the background then, quit the application upon closing the main window and do not continue to use the status notifier So, that's exactly the way we have it at the moment, isn't it? One question remains though, why do users not want KTorrent to take up 22px, but are okay with an indicator for the music player while having the music control plasmoid active too. For example I do not use a taskbar/window list, if "background applications" moved to the taskbar I would no longer be able to access them. Or why are they okay with KTorrent taking up space while downloading, but not while seeding. When downloading you likely want to open that file after it's done. To ease monitoring, it stays there. Seeding is a process that does not involve the user at all. But I don't know much about Torrent, so I could be wrong. My solution would be to allow users to move the "active" state to the popup, while the "needsAttention" one will then still be displayed in the panel. Though only after they configured system tray to do it like that, not as default. I like that idea. However, that would make monitoring system status difficult. For example at the moment I have in my systray visible (Plasma 4, though): - Amarok (paused) (btw I like that use mpris thing for that and don't have players sit in the tray approach), "Active state" - KMail 149 unread mails, "Active state" - KTP online, "Active state" - KMix, 50% volume, "Active state" None of them have the "NeedsAttentionStatus" yet still they're all useful (except maybe Amarok) Cheers, Kai Uwe ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 27.08.2014 08:16, Martin Gräßlin wrote: On Wednesday 27 August 2014 06:02:11 Philipp Stefan wrote: If the status notifiers are used like we intend them to, then the "passive" status really does not provide any benefit for the user any more. For example, if a music player idles, because the playlist has ended, then there's no difference between closing the window and reviving it again with the status notifier, or closing it and opening it again with KRunner, kickoff etc. This goes into the very broad topic of application life- cycle. The technical reality right now is that we do need to explicitly communicate lifecycle state to users because we don't have perfect state serialization - whether an app is running or not matters, because it may not come back up in the same state as when it was quit. Hmm, could you give me some examples for applications with status notifiers that handles this that way? I mean, sure applications like Inkscape and LibreOffice won't start up in the same state like when they were closed, however, applications like them don't seem to use status notifiers. I found that mostly media centred applications and those that provide background functionality like update notifiers seem to use status notifiers. Most of the ones I saw had a way or another to realize a state that is consistent with when you close the application. The only difference was startup time, but that's another story. I see your concern though. there's a technical difference: with the status notifiers the applications do not quit. They continue to run and only the main window gets hidden which can easily be restored. What you want is to quit it, but that requires application life cycle to get the application back to the state where you left it. In reality this does not exist (yet). No, we want applications to behave and use status notifiers sensibly. If your application has finished its job like e.g. an update notifier but should continue to run in the background, then use the "passive" flag. If you want to misuse the system tray as second task bar, then do not use the passive flag, but let it remain active. And if your application has finished its job and should not continue to run in the background then, quit the application upon closing the main window and do not continue to use the status notifier, nothing forces you to. We're not advocating to simply kick these applications out, but for them to examine if they use the status notifier in a consistent manner. Overall I'm with Eike here in this discussion. Just from my experience: people want to use the system tray as a kind of task bar for some windows. I regularly get bug reports about it not working or not working as expected. I don't like this taskbar feature of the system tray but we cannot deny that it's a real use case and we would piss off large numbers of users if we remove the support for passive notifiers (not to think about all the old xembed items we transform to systemtray icons). Yes it is a valid use case, however, you one has to weight it against its downside. This use case starts to collide with others and more importantly starts to clutter the system tray, because the system tray can not guess the intend of the application. It can not discriminate between applications that are in "I'm useless, please hide me" mode, the ones in "Hey, I'm using this to preserve my state" mode and the ones in the "I'm still doing something that could impact you negatively, but don't mind me please" mode. If there was a way for system tray to tell these apart then that would be rad, but I don't think there is. What's important to notice is that there are applications which would break if you remove it. Yes we are aware of that and have acknowledge it several times now. Please start to look at it from the other side. Look at what the applications provide in the system tray icon and why they are doing it. Then come up with an idea how to solve the use case, which we can then implement and after that deprecate the usage in the system tray. I did and I am trying to do that. I do not like to remove functionality, especially because that is one of KDE's strength and to avoid the notion "hurr durr all design is the same, it's GNOME all over again". My personal suggestion (which won't surprise anyone on this list) is to move the application status notifiers into the tasks applet. But that's not a really easy task and would not interact well with the remaining tasks. From my experience it's obvious that users don't want their ktorrent to take up any useable space from other applications, but it needs to be easily reachable when they want to interact with it. That's an interesting idea, but I believe it's even less enforceable and coherent than our idea, which already does not seem to be liked well :D. One question remains though, why do users not want KTorrent to take up 22px, but are okay with an indicator for the music player while having
Re: VDG suggestions and wishes about the system tray
I'm not going to chime in regarding the applications - I tend to agree with both parties - that not everything needs to be shown, yet that people like some of their applications minimized to tray (myself included - I even hide those applications from the task bar). One thing where I fully support the proposal is for plasmoids in the tray - it is a really a bad thing to have so many empty panels in - no devices, no notifications, no batteries etc. -- Cheerio, Ivan KDE, ivan.cukic at kde.org, http://ivan.fomentgroup.org/ gpg key id: 850B6F76, keyserver.pgp.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: VDG suggestions and wishes about the system tray
On Wednesday 27 August 2014 06:02:11 Philipp Stefan wrote: > >> If the status notifiers are used like we intend them to, then the > >> "passive" status really does not provide any benefit for the user any > >> more. For example, if a music player idles, because the playlist has > >> ended, then there's no difference between closing the window and > >> reviving it again with the status notifier, or closing it and opening it > >> again with KRunner, kickoff etc. > > > > This goes into the very broad topic of application life- > > cycle. The technical reality right now is that we do need > > to explicitly communicate lifecycle state to users because > > we don't have perfect state serialization - whether an app > > is running or not matters, because it may not come back up > > in the same state as when it was quit. > > Hmm, could you give me some examples for applications with status > notifiers that handles this that way? I mean, sure applications like > Inkscape and LibreOffice won't start up in the same state like when they > were closed, however, applications like them don't seem to use status > notifiers. I found that mostly media centred applications and those that > provide background functionality like update notifiers seem to use > status notifiers. Most of the ones I saw had a way or another to realize > a state that is consistent with when you close the application. The only > difference was startup time, but that's another story. I see your > concern though. there's a technical difference: with the status notifiers the applications do not quit. They continue to run and only the main window gets hidden which can easily be restored. What you want is to quit it, but that requires application life cycle to get the application back to the state where you left it. In reality this does not exist (yet). Overall I'm with Eike here in this discussion. Just from my experience: people want to use the system tray as a kind of task bar for some windows. I regularly get bug reports about it not working or not working as expected. I don't like this taskbar feature of the system tray but we cannot deny that it's a real use case and we would piss off large numbers of users if we remove the support for passive notifiers (not to think about all the old xembed items we transform to systemtray icons). What's important to notice is that there are applications which would break if you remove it. Please start to look at it from the other side. Look at what the applications provide in the system tray icon and why they are doing it. Then come up with an idea how to solve the use case, which we can then implement and after that deprecate the usage in the system tray. My personal suggestion (which won't surprise anyone on this list) is to move the application status notifiers into the tasks applet. But that's not a really easy task and would not interact well with the remaining tasks. From my experience it's obvious that users don't want their ktorrent to take up any useable space from other applications, but it needs to be easily reachable when they want to interact with it. Cheers Martin 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: VDG suggestions and wishes about the system tray
On 27.08.2014 03:24, Eike Hein wrote: On August 26, 2014 10:58:39 PM CEST, Eike Hein wrote: Except sometimes you *want* to hide things and remove them >from your immediate attention. It's a "I know where I put it" kind of thing. As a side note: Many use cases of virtual desktops and activities come down to this as well, as do Yakuake and other implementations of the enduringly popular drop-down terminal pattern. It's clearly a thing. And I find it really odd how the repeated "let's redesign the tray" plans always ignore how and why people actually use the thing (because investigating this points to user needs, and then you can ponder how to best meet them - instead of developing theoretical "this would be cleaner" models). Different users want different things and we want to make this as non-destructive as possible, however, we don't think that the current state of things is acceptable. I can assure you that we did not sit together and went "hurr durr, let's reorganise the system tray for fun" ;) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 26.08.2014 22:58, Eike Hein wrote: On 26.08.2014 22:35, Philipp Stefan wrote: Hmm, we felt that these applications should not be hidden from the user. When a user e.g. uses KTorrent and closes the window while it is only seeding, there's no telling that the application is still running, unless of course you check the popup. Except sometimes you *want* to hide things and remove them from your immediate attention. It's a "I know where I put it" kind of thing. Facilities for spatial organization are one of the key things a workspace provides. But yes, there are different approaches to this, as the dock pattern vs. Win-style window list dichotomy indicates ... But you didn't not put them there, system tray did. In this case, the developer decided that to put the application to position X when is has reached state Y. The user does have to learn what this happens in both cases unless they configured system tray to handle certain indicators differently.To be clear, we only want to change the defaults, if the user wants to hide certain applications or not than that's ok with us. We do not want to take away any configuration features. In case of music players and similar, we feel like these applications should not provide their own status notifiers. E.g. a music player should be controlled via their mpris2 interface, which can be accessed by a separate plasmoid in the system tray. This limits what music players can provide to the lowest common denominator of the MPRIS2 spec and our UI frontend for it. Apps are great things and app developers have a lot of neat ideas. I feel that limiting that idea potential would be a bad idea. Also because it's nice when apps can try out new things and prove them before they get added to the lowest common denominator. Never do things that limit what innovation can happen on your platform, I say :). That's certainly not what we want to do, I assure you :) Thing is, these are guidelines, not rules. If a music player has awesome new features then they can of course implement a status notifier, nothing prevents them from that. It's just that we do no recommend it by default. I'm sure lots of applications will have one thing or the other where they ignore the guidelines for good. If the status notifiers are used like we intend them to, then the "passive" status really does not provide any benefit for the user any more. For example, if a music player idles, because the playlist has ended, then there's no difference between closing the window and reviving it again with the status notifier, or closing it and opening it again with KRunner, kickoff etc. This goes into the very broad topic of application life- cycle. The technical reality right now is that we do need to explicitly communicate lifecycle state to users because we don't have perfect state serialization - whether an app is running or not matters, because it may not come back up in the same state as when it was quit. Hmm, could you give me some examples for applications with status notifiers that handles this that way? I mean, sure applications like Inkscape and LibreOffice won't start up in the same state like when they were closed, however, applications like them don't seem to use status notifiers. I found that mostly media centred applications and those that provide background functionality like update notifiers seem to use status notifiers. Most of the ones I saw had a way or another to realize a state that is consistent with when you close the application. The only difference was startup time, but that's another story. I see your concern though. This begs the question how many people use status notifiers that way. Currently there's a mix between apps that use status notifier like we intend them to i.e. when one opens the window again they are blank/the program is doing nothing; and then there are applications which treat the "passive" state differently. Which we would break. I think that's wishful thinking, see above - very few apps actually will come up the same way in a restart vs. an un- hide. Our application platform simply doesn't work that way yet. It might be nice if it would, and it might be sensible to decide to move into that direction. But that's a process with many steps from beginning to end. That's why I am here to discuss it. Maybe I haven't made this clear enough before, if so I apologize, but we don't want to take this into action in the near future. We know that this would break some applications, that's why we want to discuss it now. We don't see this coming to fruition till at least 5.4, well except the plasmoid part. However, as of now we feel that this destructive path is the better one to take in the long run. I'm generally not a fan of arguments along the lines of "let's intentionally break this for users to exert pressure". Change can be for the better, but there should be recourse available before a switch gets thrown IMHO. We are aware of that, we do
Re: VDG suggestions and wishes about the system tray
On August 26, 2014 10:58:39 PM CEST, Eike Hein wrote: >Except sometimes you *want* to hide things and remove them >from your immediate attention. It's a "I know where I put >it" kind of thing. As a side note: Many use cases of virtual desktops and activities come down to this as well, as do Yakuake and other implementations of the enduringly popular drop-down terminal pattern. It's clearly a thing. And I find it really odd how the repeated "let's redesign the tray" plans always ignore how and why people actually use the thing (because investigating this points to user needs, and then you can ponder how to best meet them - instead of developing theoretical "this would be cleaner" models). Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 26.08.2014 22:35, Philipp Stefan wrote: Hmm, we felt that these applications should not be hidden from the user. When a user e.g. uses KTorrent and closes the window while it is only seeding, there's no telling that the application is still running, unless of course you check the popup. Except sometimes you *want* to hide things and remove them from your immediate attention. It's a "I know where I put it" kind of thing. Facilities for spatial organization are one of the key things a workspace provides. But yes, there are different approaches to this, as the dock pattern vs. Win-style window list dichotomy indicates ... In case of music players and similar, we feel like these applications should not provide their own status notifiers. E.g. a music player should be controlled via their mpris2 interface, which can be accessed by a separate plasmoid in the system tray. This limits what music players can provide to the lowest common denominator of the MPRIS2 spec and our UI frontend for it. Apps are great things and app developers have a lot of neat ideas. I feel that limiting that idea potential would be a bad idea. Also because it's nice when apps can try out new things and prove them before they get added to the lowest common denominator. Never do things that limit what innovation can happen on your platform, I say :). (That's not a knock on MPRIS2 - I wrote the MPRIS2 support for several of our media players and other apps and think it's a really cool tech.) If the status notifiers are used like we intend them to, then the "passive" status really does not provide any benefit for the user any more. For example, if a music player idles, because the playlist has ended, then there's no difference between closing the window and reviving it again with the status notifier, or closing it and opening it again with KRunner, kickoff etc. This goes into the very broad topic of application life- cycle. The technical reality right now is that we do need to explicitly communicate lifecycle state to users because we don't have perfect state serialization - whether an app is running or not matters, because it may not come back up in the same state as when it was quit. This begs the question how many people use status notifiers that way. Currently there's a mix between apps that use status notifier like we intend them to i.e. when one opens the window again they are blank/the program is doing nothing; and then there are applications which treat the "passive" state differently. Which we would break. I think that's wishful thinking, see above - very few apps actually will come up the same way in a restart vs. an un- hide. Our application platform simply doesn't work that way yet. It might be nice if it would, and it might be sensible to decide to move into that direction. But that's a process with many steps from beginning to end. On the mobile platforms, many of which do work this way, this work was actually driven more by resource constraints than design thinking, and that's not a pressure we've had acting on us, and it shows. However, as of now we feel that this destructive path is the better one to take in the long run. I'm generally not a fan of arguments along the lines of "let's intentionally break this for users to exert pressure". Change can be for the better, but there should be recourse available before a switch gets thrown IMHO. Hmm, KTorrent would only eat bandwidth when it's downloading/seeding a torrent, or am I mistaken? In our, "corrected" model, the user would still have access to that functionality. If KTorrent were to change how they use the notifiers then the notifier should have the "active" status, not "passive". But how does your model deal with setting the speed to 0? (= Pause.) You and the user might have a different idea of what "active" means, and this model means the user needs to learn about what yours is and keep track of it to know where and when to find the app. This strikes me as mentally much more complicated than "I put the app into the tray, it will be in the tray". Downloading/seeding is an action, however, that takes up bandwidth which is important for the user. You wouldn't want your music player to hide its notifier (it shouldn’t have it own) when you are listening to a stream either, would you? Personally I have KTorrent hidden by default and Cantata shown by default. That's a binning based on how frequently I need to inter- act with them. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 26.08.2014 22:00, Eike Hein wrote: On 26.08.2014 21:26, Philipp Stefan wrote: This would, of course, break some applications like KTorrent. How would it behave ideally? When you open KTorren and there are no torrents configured there should not be an indicator as the applications simply does nothing for now (passive). As soon as one adds a torrent a notifiers should be shown (active). The user can then close or minimize the window and do what they do. When a torrent finishes downloading the status of the indicator should change to "needsAttention" to notify the user that the download has finished. If the user then does not remove the torrent from KTorrent i.e. it continues seeding, the indicator should stay in an "active" state, not "passive" as it is now. I feel this ignores some of the use cases that status notifiers currently serve in practice, and ignores how users arrange their workspace spatially. Certain kinds of apps - KTorrent and music players among them - essentially perform background activities for most of the time they are running. They performs task at the user's behest (play music, download file), but accomplish them without continuous direct involvement by the user. Yet this activity must occassionally be managed, e.g. when it collides with other activity on the system. The status notifier context menu tends to wind up providing these kinds of actions: KTorrent lets you set speed limits from there, music players let you pause play- back, and so on. They're great conveniences. At the same time the need to use them is infrequent enough that you may not want to make those access points permanent residents of your panel. You want to keep them in reach, but you don't need them part of your working set the entire time. This is what having them in the popup (and not on the Task Manager) provides. Hmm, we felt that these applications should not be hidden from the user. When a user e.g. uses KTorrent and closes the window while it is only seeding, there's no telling that the application is still running, unless of course you check the popup. In case of music players and similar, we feel like these applications should not provide their own status notifiers. E.g. a music player should be controlled via their mpris2 interface, which can be accessed by a separate plasmoid in the system tray. If the status notifiers are used like we intend them to, then the "passive" status really does not provide any benefit for the user any more. For example, if a music player idles, because the playlist has ended, then there's no difference between closing the window and reviving it again with the status notifier, or closing it and opening it again with KRunner, kickoff etc. Organizing stuff into rings based on how frequently we need them is very basic human behavior, and you can find this pattern repeated in our interfaces every where. People put apps they launch frequently into their panel, have a second tier of less-frequently launched apps in their menu favorites, and finally the menu pool backing them both. Apps have tool- bars and menus. And so on. Hiding "passive" status notifier items robs the user of an entire tier of organization when deciding how near/far they want to place a running app. This begs the question how many people use status notifiers that way. Currently there's a mix between apps that use status notifier like we intend them to i.e. when one opens the window again they are blank/the program is doing nothing; and then there are applications which treat the "passive" state differently. Which we would break. Unless someone flagged how these notifiers should be displayed individually they end up with a mix of useless notifiers and useful ones, which clutters the popup. If there's a way to detect which notifier provides useful information/access to useful functionality then we can go for hiding only the "useless" ones. However, as of now we feel that this destructive path is the better one to take in the long run. Even this organization issue aside, you'd be killing off a means to manage the app without bringing its window to the front (and thus disrupting whatever the user may be doing - imagine they want to restrict KTorrent's bandwidth usage during a VoIP call). Hmm, KTorrent would only eat bandwidth when it's downloading/seeding a torrent, or am I mistaken? In our, "corrected" model, the user would still have access to that functionality. If KTorrent were to change how they use the notifiers then the notifier should have the "active" status, not "passive". We feel like the "passive" status should only be used when the application really does nothing interesting for the user. Downloading/seeding is an action, however, that takes up bandwidth which is important for the user. You wouldn't want your music player to hide its notifier (it shouldn’t have it own) when you are listening to a stream either, would you? […] But we don't have that facility righ
Re: VDG suggestions and wishes about the system tray
On Tuesday 26 August 2014, Eike Hein wrote: > On 26.08.2014 21:26, Philipp Stefan wrote: > > This would, of course, break some applications like KTorrent. How would > > it behave ideally? When you open KTorren and there are no torrents > > configured there should not be an indicator as the applications simply > > does nothing for now (passive). As soon as one adds a torrent a > > notifiers should be shown (active). The user can then close or minimize > > the window and do what they do. When a torrent finishes downloading the > > status of the indicator should change to "needsAttention" to notify the > > user that the download has finished. If the user then does not remove > > the torrent from KTorrent i.e. it continues seeding, the indicator > > should stay in an "active" state, not "passive" as it is now. > > I feel this ignores some of the use cases that status notifiers > currently serve in practice, and ignores how users arrange their > workspace spatially. also, from a pure operative standpoint, it would become impossible to close several applications -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: VDG suggestions and wishes about the system tray
On 26.08.2014 21:26, Philipp Stefan wrote: This would, of course, break some applications like KTorrent. How would it behave ideally? When you open KTorren and there are no torrents configured there should not be an indicator as the applications simply does nothing for now (passive). As soon as one adds a torrent a notifiers should be shown (active). The user can then close or minimize the window and do what they do. When a torrent finishes downloading the status of the indicator should change to "needsAttention" to notify the user that the download has finished. If the user then does not remove the torrent from KTorrent i.e. it continues seeding, the indicator should stay in an "active" state, not "passive" as it is now. I feel this ignores some of the use cases that status notifiers currently serve in practice, and ignores how users arrange their workspace spatially. Certain kinds of apps - KTorrent and music players among them - essentially perform background activities for most of the time they are running. They performs task at the user's behest (play music, download file), but accomplish them without continuous direct involvement by the user. Yet this activity must occassionally be managed, e.g. when it collides with other activity on the system. The status notifier context menu tends to wind up providing these kinds of actions: KTorrent lets you set speed limits from there, music players let you pause play- back, and so on. They're great conveniences. At the same time the need to use them is infrequent enough that you may not want to make those access points permanent residents of your panel. You want to keep them in reach, but you don't need them part of your working set the entire time. This is what having them in the popup (and not on the Task Manager) provides. Organizing stuff into rings based on how frequently we need them is very basic human behavior, and you can find this pattern repeated in our interfaces every where. People put apps they launch frequently into their panel, have a second tier of less-frequently launched apps in their menu favorites, and finally the menu pool backing them both. Apps have tool- bars and menus. And so on. Hiding "passive" status notifier items robs the user of an entire tier of organization when deciding how near/far they want to place a running app. Even this organization issue aside, you'd be killing off a means to manage the app without bringing its window to the front (and thus disrupting whatever the user may be doing - imagine they want to restrict KTorrent's bandwidth usage during a VoIP call). It's possible to imagine alternative UIs, e.g. in desktops using the dock pattern to manage tasks, it would usually not be possible to hide the delegate representing the running KTorrent from the dock, and the actions could be placed in its context menu. But we don't have that facility right now, and removing something without recourse strikes me as a bad idea. Cheers, Eike ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
