VDG suggestions and wishes about the system tray

[Philipp Stefan]

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