VDG suggestions and wishes about the system tray

[Eike Hein]

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 ...


> 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 not a knock on MPRIS2 - I wrote the MPRIS2
support for several of our media players and other apps
and think it's a really cool tech.)


> 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.


> 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.

On the mobile platforms, many of which do work this way,
this work was actually driven more by resource constraints
than design thinking, and that's not a pressure we've had
acting on us, and it shows.


> 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.


> 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.)

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".


> 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.


Cheers,
Eike