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