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.
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
