On 27.08.2014 08:16, Martin Gräßlin wrote:
On Wednesday 27 August 2014 06:02:11 Philipp Stefan wrote:
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.
there's a technical difference: with the status notifiers the applications do
not quit. They continue to run and only the main window gets hidden which can
easily be restored.
What you want is to quit it, but that requires application life cycle to get
the application back to the state where you left it. In reality this does not
exist (yet).
No, we want applications to behave and use status notifiers sensibly. If
your application has finished its job like e.g. an update notifier but
should continue to run in the background, then use the "passive" flag.
If you want to misuse the system tray as second task bar, then do not
use the passive flag, but let it remain active. And if your application
has finished its job and should not continue to run in the background
then, quit the application upon closing the main window and do not
continue to use the status notifier, nothing forces you to. We're not
advocating to simply kick these applications out, but for them to
examine if they use the status notifier in a consistent manner.
Overall I'm with Eike here in this discussion. Just from my experience: people
want to use the system tray as a kind of task bar for some windows. I
regularly get bug reports about it not working or not working as expected. I
don't like this taskbar feature of the system tray but we cannot deny that
it's a real use case and we would piss off large numbers of users if we remove
the support for passive notifiers (not to think about all the old xembed items
we transform to systemtray icons).
Yes it is a valid use case, however, you one has to weight it against
its downside. This use case starts to collide with others and more
importantly starts to clutter the system tray, because the system tray
can not guess the intend of the application. It can not discriminate
between applications that are in "I'm useless, please hide me" mode, the
ones in "Hey, I'm using this to preserve my state" mode and the ones in
the "I'm still doing something that could impact you negatively, but
don't mind me please" mode.
If there was a way for system tray to tell these apart then that would
be rad, but I don't think there is.
What's important to notice is that there
are applications which would break if you remove it.
Yes we are aware of that and have acknowledge it several times now.
Please start to look at it from the other side. Look at what the applications
provide in the system tray icon and why they are doing it. Then come up with
an idea how to solve the use case, which we can then implement and after that
deprecate the usage in the system tray.
I did and I am trying to do that. I do not like to remove functionality,
especially because that is one of KDE's strength and to avoid the
notion "hurr durr all design is the same, it's GNOME all over again".
My personal suggestion (which won't surprise anyone on this list) is to move
the application status notifiers into the tasks applet. But that's not a
really easy task and would not interact well with the remaining tasks. From my
experience it's obvious that users don't want their ktorrent to take up any
useable space from other applications, but it needs to be easily reachable
when they want to interact with it.
That's an interesting idea, but I believe it's even less enforceable and
coherent than our idea, which already does not seem to be liked well :D.
One question remains though, why do users not want KTorrent to take up
22px, but are okay with an indicator for the music player while having
the music control plasmoid active too. Or why are they okay with
KTorrent taking up space while downloading, but not while seeding.
My solution would be to allow users to move the "active" state to the
popup, while the "needsAttention" one will then still be displayed in
the panel. Though only after they configured system tray to do it like
that, not as default.
Cheers
Phil
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
