I think I should maybe clarify a few things here as I feel that my
original post has left behind the idea in some that we sought a solution
in search for a problem.
So what is the problem we are trying to solve? The problem is that
currently the system tray icons behave unpredictable to the user or
formulated differently: The user can not predict the status of an
application based on where its icon shows up in the system tray, so the
burden of differentiating and rating if an application provides
important information lays on the user instead of the
application/application developer. This problem exists to some extent in
the panel part of the system tray, but it is most apparent in the popup.
In the popup we have plasmoids which hold no information for the user
except when they do, like the battery plasmoid when the battery is fully
charged but is still used to adjust the monitor brightness. The same
thing can be said about status notifiers. So the popup loses its
function as an area for information that is still somewhat relevant to
the user, but not relevant enough to warrant constant display, because
the actual important parts are buried beneath a flood of icons/notifiers
with no relevant information at all.
The idea of this area is sound, but it does not work with the tool at hand.
The very best solution would be to add a 4th state to SNI, a
"needsHiding" state, if you will. However, we share this specification
with another DE, Unity. So there are several possibilities how things
could play out:
1. Canonical accepts the changes and changes their system tray to
accommodate the new behaviour. All applications using status
notifiers would have to be adapted. This would also solve the issue
that some KDE applications' notifier is broken in Unity e.g.
KTorrent. I'm not sure how realistic this option is, given that they
seem very happy with how their implementation works.
2. We adopt Unity's policy in handling the "passive" status. Only some
applications like KTorrent would have to be adapted, but would now
be working in both Plasma and Unity again.
3. We add a 4th status to SNI without Canonical's agreement. We'd end
up with xembed, GNOME Shell's thing, appindicators, and our new SNI
– 4 with each other incompatible solutions. The only place where we
can realistically pull this off is system tray plasmoids, as they
would not work in Unity anyway to my information.
4. Do nothing, the system tray popup remains as cluttered and space
wasting as always.
Another thing to clarify: The proposal of the changes on plasmoids and
status notifiers are _not_ independent of each other. If the changes to
plasmoids are accepted, then we would have improved the their
usefulness, but the overall problem would still be there. We need to
have a way to separate the useful "passive" icons from the useless in
order to improve the situation.
We think that the most realistic option is 2., but the best solution
would of course be 1. I have tried to reach out to Canonical, but I had
not much luck, probably because I do not know the right people.
What's important to note is that we really did not came up with this out
of the blue, and we did assess the situation, what applications are
doing and why. We really just want to improve the situation and think
that 2. is the most realistic option while encompassing relatively
little work.
We don't like to break work flows either. If we can pull of 1. that
would be rad, but I really doubt it's going to happen any time soon.
Cheers
Phil
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
