unity-design team mailing list archive

[Mark Shuttleworth <mark@xxxxxxxxxx>]

On 18/05/10 19:43, Dylan McCall wrote:
> On Tue, May 18, 2010 at 10:38 AM, David Hamm <davidthamm@xxxxxxxxx> wrote:
>   
>> Close=quit, some apps could just minimize to tray by default (music
>> player). The music tray would already provide more function then the
>> taskbar, no reason to minimize it there.
>>     
> That doesn't make sense to me. How, then, do we differentiate between
> these two? How do you quit Rhythmbox if Close=Quit, and why does
> Media›Close in its menu not do the same thing as Media›Quit? ;)
>   

The critical pieces in MPT's argument are that:

 - apps which also provide services should show up in the panel whether
or not they are running
 - "state should be preserved across sessions"
 - that state should also be visible in a persistent fashion, through
the panel ("what was playing")
 - changing state ("going online" or "playing music") should launch the
application if needed.

Putting those together, you get to a point where *it doesn't matter*
that the application quit. Consider Rhythmbox. You are listening to a
song and you close the window. You didn't say "stop playing", you just
closed a window. Rhythmbox continues to play in the background. You can
pause and start the music, or change playlists, through the sound menu.

Now, say you've got a playlist playing, and you stop playback. Then you
close the window. The point of the persistent state, *and* the continued
expression in the sound menu when not playing, means that you can still
have *exactly the same experience*. You can click on the sound menu, see
what *was* playing (and hence, what will happen if you press play). If
you click play, the app is launched, and you listen to your music.
Simple. No window required - it's playing in the background.

I think this handles the issues very cleanly and elegantly.

Mark

Attachment: signature.asc
Description: OpenPGP digital signature