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