[KDE Usability] Close button: reaaly close or go to system tray?

[Diego Moya]

2010/1/26 Jos Poortvliet wrote:
> I think this isue transcends the close button thing. At camp KDE a few ppl
> discussed this: there is a category of applications, currently often
> 'closing' to the systray, which is indeed more service lik than other apps.
> A word processor or a webbrowser is supposed to be there while you work with
> it and go when you no longer need it. However, music players, chat
> applications and more (often social media stuff) is different: they need to
> stay available in the background. The systray is a poor place for such
> applications/services and another solution must be found for this.

I'm not sure media players fit in the "service" model. It surely
doesn't for video players, which follow the "document" model - if I'm
watching a movie or a tv stream, when I close it, it should go for
good. Should audio-only really be different?


The chat application is a better fit, because you have an "online
presence" and separate conversation windows; closing the last
conversation isn't meant to remove your online presence.



> Anyway. We won't sove it in this thread but i hope some developers
> interested in this issue will start thinking and experimenting. And you
> usability ppl might have iedeas too.

IMO the best solution for this case would be not having just one
systray-messaging area, but having several dedicated copies of a
"service controler" plasmoid. The user could redirect any systray
information for that application to the one I set up (maybe based on
filters by message type). For applications not associated to a tray,
the service would end as soon as the last application window is
closed.

That way I could have one systray plasmoid for multimedia on my
"leisure" activity, a "system-systray" plasmoid on the desktop showing
battery life and connectivity, and a "warnings" plasmoid on the panel
- all of them configured by myself, not predefined in application
code. I don't know if this is the direction the systray redesign talks
are facing, but is the one that makes more sense to me - and the more
KDEish: give power to the user.



2010/1/26 Andreas Pakulat wrote:

> And what happens to poor souls like me who don't have a single plasmoid
> anywhere (except for the digital clock in the panel)? I simply don't have
> any empty space on my desktop to put a plasmoid there and having to hide a
> window just to reach a plasmoid is not an option IMHO.

Aren't plasmoids supposed to fit on panels? If you put that new
plasmoid in the panel you'll get exactly the same behavior that if you
put the a "service notification" in the systray, except that you get
two separate areas instead of one.


> For example, creating a special service plasmoid area; making these apps
> split back- and frontend and upon closing keep only the backend running; or
> have a kded or plasma dataengine or so take the place of the app's
> functionality. Compare having the 'news' plasma applet, and whenever you
> want more info you click the 'full app' button on the applet (new in plasma
> 4.4).

For a media player, this would mean having a "media player" in the
background, and a "playlist editor" (which prepares music for the
background service) as the complex front-end. I like the idea, but
this still doesn't work well if I'm watching a single media file
(where closing the main window should stop playback).

Maybe there should be a clear distinction between stream information
and document-centered one. The first one would be music (for audio) or
MTV videoclips (for video); the second one could be for example movies
(video) and sound effects (audio only).

The first kind should be handled by the "library manager" (Amarok)
connected to the background service, while a single document opened
from the file manager should play in a stand-alone simple play window
and not in the service.

This model works well either for audio and video; they can even
interact, say I'm playing music in the background and want to review a
sound .wav file; or play a video on YouTube. The stand-alone player
could signal the background streaming service to pause while it's
playing, and resume the service when it's closed.