VDG suggestions and wishes about the system tray

[Philipp Stefan]

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 don't like it either. However, currently the 
system tray is a mess when it comes to consistent behaviour. If there 
was a way for system tray to intelligently judge which application can 
be displayed and which can be hidden then we'd go that path. Right now, 
however, we have applications that really don't provide anything useful 
when their indicator has the "passive" flag, then we applications that 
assume the "passive" state when they still perform potentially 
disrupting actions like taking up bandwidth and last but not least we 
have applications that use the "passive" state to declutter the task 
manager while preventing the application from being terminated.
We recognised the last case as valid, as well as the first one. These 
three applications are not neatly separated though, they all use the 
same state to perform their actions.
We could, for example, check if an application is already running when 
one uses Krunner et all and reveal their window when it indeed does, so 
that the last case is covered. But this would only shift the difficulty 
in managing these different applications states from one part of plasma 
to the other.
The "passive" state in the popup is a very nice idea in theory, but we 
have to deal with applications that simply do not fit in with the rest 
and there's no way of dealing with them unless we either change the 
applications, plasma or do nothing. Doing nothing strikes us as the 
worst alternative.
>> 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.)
It would still be "active" as it has not yet finished its task. "Pause" 
should be a temporary action so I don't see why this would warrant to 
move the indicator and break the spatial model of the user. I imagine 
this: You want to quickly pause the torrent for a second to free up 
bandwidth for other applications and you do so by using the indicator. 
When you want to revert this action your indicator is suddenly gone. You 
will find it in the popup, but this behaviour is a learned one in any 
case. And because every application currently uses status notifiers 
differently there's no way for the user to form a general mental model 
of how these indicator behave. This doesn't strike us as something 
desirable.
If you want to completely stop the torrent you should toggle the "stop" 
action in KTorrent. And when you have stopped the torrent(s) then 
there's not difference between closing and startup state.
> 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".
But that's already the case! Not the user decides where the indicator 
can be found depending on the state, but the developer does. The user 
does not influence the situation unless they configured system tray to 
do so, in which case this option stays available.
You already have to remember where to find the indicator of application 
X when it assumes state Y individually, because application Z might not 
behave the same way in state Y, but application Q only behaves like 
application X does in state Y when it does not have any useful 
information for the user.
We want to make the behaviour more predictable so you really can say "I 
put the app into the tray and it will stay there", and it strikes us 
this can only be achieved right now with a bit of pressure. The 
pressure-less path has led us to this rather messy situation in first place.
>> 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.
You would still be able to configure that. We do not want to take away 
the ability to configure such things. We are merely concerned with the 
default settings. I don't see the problem here.