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 right now,
and removing something without recourse strikes me as a bad
idea.
I agree, it should be avoided when possible. However, currently we have
a bunch of applications and all use status notifiers differently, so we
have to think about how we can bring clarity into this situation. We
found that we should enforce a policy more strictly. It is a painful
action in the short term but the long term value, a cleaned up system
tray) should not be ignored either.
Also, with KF5 etc. how would KTorrent et al manage to function on e.g.
Unity. Isn't the whole point of status notifiers to provide a mechanism
for applications to provide functionality accross DEs? In Unity
"passive" notifiers can't be accessed by the user either.
I also found, but I could be wrong, that the majority off applications
use notifiers the way we propose, while only a few deviate from that
e.g. KTorrent, so I'm not sure if we can get the other applications to
work more like KTorrent.
If there's a way to clean up the system tray a bit without disrupting
these applications then I am all for it.
Cheers
Phil
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
