VDG suggestions and wishes about the system tray

[Philipp Stefan]

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