Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chow Loong Jin wrote on 15/02/11 17:05: On Tuesday 08,February,2011 09:36 PM, Matthew Paul Thomas wrote: A window's close button should close the window. Anything else the program does should aim for the least overall distraction. Please correct me if I am wrong, but does this not mean that the original behaviour of having the media players (Banshee and Rhythmbox) close their windows, but remain running in the background, ready to resume at a moment's notice, is the correct behaviour after all? I don't claim to be an expert on when a media player should unload itself. What I do claim is that hardly anyone else is an expert on that topic either. :-) It's something best worked out by the Banshee and Rhythmbox developers. It seems to me that the original behaviour (as opposed to the current behaviour) closes the window and yields the least overall distraction, thus complying with the statement you made. The user does not need to know that the media player is actually still running in the background. The Quit action does create a bit of confusion in that case though. It does. That much, at least, is easily solved: rename it to Close. http://design.canonical.com/2011/03/quit/ - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk12DzcACgkQ6PUxNfU6ecp6pACeP4VfyMoK39gEq9Y+GoURpQJR p4QAnis8F6cPiqHs6MvElEAZbWPRCWtg =GLek -END PGP SIGNATURE- ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On Tue, 2011-02-08 at 13:36 +, Matthew Paul Thomas wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for raising this, Brett. Brett Cornwall wrote on 07/02/11 17:28: Hi, Coming from bug 658590 https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/658590. I am arguing the sanity of having media players close when no music is playing. Since this spec assumes that the user has no purpose for the application when closing wouldn't it be safe to say that any wasted RAM would be shifted to the swap partition? That's what it's for. The end goal should be that quit is something the computer takes care of. Humans should no longer have to care whether a program is running or not. Contrary to the above bug; I had problems with this behavior. With the new sound menu changes, I wanted to quit Banshee while it was running(playing) and there is no way to quit Banshee! The Quit menu item has been changed to a Close I was left wondering what to do, and then remembered this thread, else I would have been completely lost.. :s So now to Quit I have to first Pause and then choose to Quit/Close the app. Which was just a simpler single action with a Quit menu item. Now we have the same close button doing two actions. If I was a new user, once I noticed that Close button minimizes Banshee to the sound menu, how would I realize that very same button would be a quit action only when I pause the player? -- Cheers, Vish ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On Tue, Feb 8, 2011 at 4:54 PM, Brett Cornwall brettcornw...@gmail.comwrote: Well, all that is written in the spec is: *A compliant player should also keep playing if you close its window while it is playing; exit if you close its window while it is not playing; and remember exact state across sessions, so that after exit and relaunch it is as if the player had never exited.* I honestly don't see the benefit in such an action other than conserving RAM. But that's the purpose of swap, isn't it? If RAM were the reason for this behavior then it's putting more headache and CPU usage on those that can handle lots of programs in order to reimplement an already-existing functionality dedicated to those that run out of resources. I'm curious for an explanation as I just don't understand the motivation. Surely getting all these players to comply with preserving their exact state is going to take some time to acoomplish. Why spend all the resources on something so unexplained and seemingly trivial? People turn their computers off from time to time. You cannot expect everyone to have his/her computer running (or, at least suspended) day and night in an endless session. As far as I'm concerned, perfect state saving is the right behavior for all applications, not only for music players. I want to be able to end my session at any time and for whatever reason I may have, without having to expend 10 minutes trying to restore the my session state afterwards. Cheers, Martín ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On 02/15/2011 04:06 AM, Martín Soto wrote: People turn their computers off from time to time. You cannot expect everyone to have his/her computer running (or, at least suspended) day and night in an endless session. My argument is not against session saving - it's against the behavior of closing the media player instead of hiding it to the indicators (like the rest of the housed applications). I advise you re-read the messages. -- -Brett Cornwall ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
This here was and is imo be the most clear and straightforward contribution to the problem this thread is trying to address: On Tue, Feb 8, 2011 at 14:36, Matthew Paul Thomas m...@canonical.com wrote: A window's close button should close the window. Anything else the program does should aim for the least overall distraction. In the perfect implementation, Rhythmbox or Banshee would then have a way of continuing playback where you last left off.. Meaning even if Rhythmbox or Banshee was quit somehow, it should resume right where you left it upon quit, by simply pressing the Play button in the Sound Menu's playback controls. If R or B would take longer to load because it was unfortunately quit beforehand, then so be it, but distraction here would be to make the user go back into the library / manager view to resume playback where it was last stopped. 2011/2/15 Brett Cornwall brettcornw...@gmail.com On 02/15/2011 04:06 AM, Martín Soto wrote: People turn their computers off from time to time. You cannot expect everyone to have his/her computer running (or, at least suspended) day and night in an endless session. My argument is not against session saving - it's against the behavior of closing the media player instead of hiding it to the indicators (like the rest of the housed applications). I advise you re-read the messages. Nothing wrong with session saving imo, even though it never really worked in GNOME, not even for Nautilus windows, which imo is a sad thing (or did i use/configure it wrongly?). ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On 02/15/2011 10:18 AM, frederik.nn...@gmail.com wrote: This here was and is imo be the most clear and straightforward contribution to the problem this thread is trying to address: On Tue, Feb 8, 2011 at 14:36, Matthew Paul Thomas m...@canonical.com mailto:m...@canonical.com wrote: A window's close button should close the window. Anything else the program does should aim for the least overall distraction. In the perfect implementation, Rhythmbox or Banshee would then have a way of continuing playback where you last left off.. Meaning even if Rhythmbox or Banshee was quit somehow, it should resume right where you left it upon quit, by simply pressing the Play button in the Sound Menu's playback controls. If R or B would take longer to load because it was unfortunately quit beforehand, then so be it, but distraction here would be to make the user go back into the library / manager view to resume playback where it was last stopped. Nothing wrong with session saving imo, even though it never really worked in GNOME, not even for Nautilus windows, which imo is a sad thing (or did i use/configure it wrongly?). Having to reload the application again is going to make the environment feel quite a bit slower. Banshee is a complete media manager suite and with that comes a weighty startup. I do understand that tablets are now in the equation but an overflow of applications has been handled in a better manner for years now (swap). Should we lower the usability for one specific type of hardware? Tomboy takes quite an extraordinary amount of RAM as well (more than Rhythmbox in my case) but I don't see Ayatana jumping to break anything on that front. Also, I will ask: Will this perfect implementation make it to natty final? Or will this be a horrifically broken first step? The indicator applet was a pretty useless mess for a few releases until it matured. Up until that point it wrecked the desktop experience, being little more than a little chat client launcher. So far the implementation has been to have Rhythmbox close (without session saving at all). It's been sitting there, broken. What's new in Natty? Banshee has been broken as well. Will 11.10 feature Exaile and Amarok closing and 12.04 feature session saving? There is an unfortunate lack of proper planning in these features - if you're going to break things, break 80 percent of it on the first go, not 15 percent every release. -- -Brett Cornwall ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On Tuesday 08,February,2011 09:36 PM, Matthew Paul Thomas wrote: A window's close button should close the window. Anything else the program does should aim for the least overall distraction. Please correct me if I am wrong, but does this not mean that the original behaviour of having the media players (Banshee and Rhythmbox) close their windows, but remain running in the background, ready to resume at a moment's notice, is the correct behaviour after all? It seems to me that the original behaviour (as opposed to the current behaviour) closes the window and yields the least overall distraction, thus complying with the statement you made. The user does not need to know that the media player is actually still running in the background. The Quit action does create a bit of confusion in that case though. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
Hi, Coming from bug 658590 https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/658590. I am arguing the sanity of having media players close when no music is playing. Since this spec assumes that the user has no purpose for the application when closing wouldn't it be safe to say that any wasted RAM would be shifted to the swap partition? That's what it's for. Constantly spending resources on starting and stopping a program can in the long run add up to a lot of wasted performance. Media players are among the most frequently accessed programs on computers - Should the CPU be hogged that much? Most media players scan the music library upon startup - When I start Banshee or Rhythmbox up it takes about a minute for the programs to scan my music. It doesn't make sense to have it do that every time I want to look through my library. The close button's purpose has been obfuscated because of the systray and now it's been even furthur confused. Close /should/ close the program - however, invoking the close button to do different actions depending on the state of the program does not follow any sensical design - it has buried the design down a hole of larger complexity. Thank you for your time. -- -Brett Cornwall ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
The close button's purpose has been obfuscated because of the systray and now it's been even furthur confused. Close /should/ close the program - however, invoking the close button to do different actions depending on the state of the program does not follow any sensical design - it has buried the design down a hole of larger complexity. Thank you for your time. -- -Brett Cornwall I think where we have a problem here is where we often make that first assumption. People keep making different assumptions here. I'll start by describing the exact opposite philosophy, which I for one am biased towards: The close button on a window closes a window; one of many possible views into an application. GTK's standard response encourages that behaviour. That same process could be simultaneously providing a web UI, a spoken UI and a GUI; the user has simply stopped caring about the GUI. Meanwhile, the SIGQUIT signal exits a process. The shell has nothing to tell an entire application (which could be a number of processes) to quit, except whatever happens to be in the application itself. So, there is some disagreement on this point. I don't think one side is particularly right or wrong. Both sides need something more than what we have right now, which is kind of a halfway solution either way :) I think app lifecycle needs to be clearly specified, one way or another, further upstream. The Gnome Shell has this same problem with its application-specific menu on the top panel, so there should be a lot of movement on this front in the future. Here's Apple on the subject, for example: http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/CoreApplication/CoreApplication.html I think you have a really good point about the wastefulness of blindly exiting a music player in all cases. Android does something cool here, keeping an application running until it's really worthwhile to close it completely. Android has the natural benefit that it can actually manage and track “Applications” in an accurate way, so that's probably a good starting point over here. Right now we are at the mercy of each application to close itself when the user is finished with it, and/or to present itself when it's working in the background. None of them do that particularly well, though some do it better than others. Dylan ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
On 02/07/2011 02:25 PM, Dylan McCall wrote: The close button's purpose has been obfuscated because of the systray and now it's been even furthur confused. Close /should/ close the program - however, invoking the close button to do different actions depending on the state of the program does not follow any sensical design - it has buried the design down a hole of larger complexity. Thank you for your time. -- -Brett Cornwall I think where we have a problem here is where we often make that first assumption. People keep making different assumptions here. I'll start by describing the exact opposite philosophy, which I for one am biased towards: The close button on a window closes a window; one of many possible views into an application. GTK's standard response encourages that behaviour. That same process could be simultaneously providing a web UI, a spoken UI and a GUI; the user has simply stopped caring about the GUI. Meanwhile, the SIGQUIT signal exits a process. The shell has nothing to tell an entire application (which could be a number of processes) to quit, except whatever happens to be in the application itself. So, there is some disagreement on this point. I don't think one side is particularly right or wrong. Both sides need something more than what we have right now, which is kind of a halfway solution either way :) I think app lifecycle needs to be clearly specified, one way or another, further upstream. The Gnome Shell has this same problem with its application-specific menu on the top panel, so there should be a lot of movement on this front in the future. Here's Apple on the subject, for example: http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/CoreApplication/CoreApplication.html I think you have a really good point about the wastefulness of blindly exiting a music player in all cases. Android does something cool here, keeping an application running until it's really worthwhile to close it completely. Android has the natural benefit that it can actually manage and track “Applications” in an accurate way, so that's probably a good starting point over here. Right now we are at the mercy of each application to close itself when the user is finished with it, and/or to present itself when it's working in the background. None of them do that particularly well, though some do it better than others. Dylan Thank you for clarifying, Dylan. I meant precisely what you explained - While I really don't have much of a belief in /how/ programs are kept alive I do not approve of this half-implementation. I think 'closing' the application is a sub-par method of telling the application to hide in the sound indicator: I think it's even worse that it now only *sometimes* hides. I would find another button (windicator?) that would deal specifically with programs that can integrate via the indicators (not ideal, just shooting something up). As of now it feels broken. The indicator applets are designed only for a select group of programs. We launch and handle certain applications from the top right of the screen and handle the others from the launcher on the left hand side (as of unity). There's already a huge tear in the consistency; however, the top right all houses applications that do not quit on close. Why make an exception to the music player? Should my chat client close when I'm not talking to anyone? I believe this behavior is further bludgeoning a hole in a consistent and predictable desktop experience. As for Android, it's an interesting concept but I wonder about its effectiveness in a non-portable environment. -- -Brett Cornwall brettcornw...@gmail.com ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications
Hi Brett, On Mon, Feb 7, 2011 at 20:47, Brett Cornwall brettcornw...@gmail.comwrote: On 02/07/2011 02:25 PM, Dylan McCall wrote: The close button's purpose has been obfuscated because of the systray and now it's been even furthur confused. Close /should/ close the program - however, invoking the close button to do different actions depending on the state of the program does not follow any sensical design - it has buried the design down a hole of larger complexity. Thank you for your time. -- -Brett Cornwall I think where we have a problem here is where we often make that first assumption. People keep making different assumptions here. I'll start by describing the exact opposite philosophy, which I for one am biased towards: The close button on a window closes a window; one of many possible views into an application. GTK's standard response encourages that behaviour. That same process could be simultaneously providing a web UI, a spoken UI and a GUI; the user has simply stopped caring about the GUI. Meanwhile, the SIGQUIT signal exits a process. The shell has nothing to tell an entire application (which could be a number of processes) to quit, except whatever happens to be in the application itself. So, there is some disagreement on this point. I don't think one side is particularly right or wrong. Both sides need something more than what we have right now, which is kind of a halfway solution either way :) I think app lifecycle needs to be clearly specified, one way or another, further upstream. The Gnome Shell has this same problem with its application-specific menu on the top panel, so there should be a lot of movement on this front in the future. Here's Apple on the subject, for example:http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/CoreApplication/CoreApplication.html I think you have a really good point about the wastefulness of blindly exiting a music player in all cases. Android does something cool here, keeping an application running until it's really worthwhile to close it completely. Android has the natural benefit that it can actually manage and track “Applications” in an accurate way, so that's probably a good starting point over here. Right now we are at the mercy of each application to close itself when the user is finished with it, and/or to present itself when it's working in the background. None of them do that particularly well, though some do it better than others. Dylan Thank you for clarifying, Dylan. I meant precisely what you explained - While I really don't have much of a belief in *how* programs are kept alive I do not approve of this half-implementation. I think 'closing' the application is a sub-par method of telling the application to hide in the sound indicator: I think it's even worse that it now only *sometimes* hides. I would find another button (windicator?) that would deal specifically with programs that can integrate via the indicators (not ideal, just shooting something up). As of now it feels broken. The indicator applets are designed only for a select group of programs. We launch and handle certain applications from the top right of the screen and handle the others from the launcher on the left hand side (as of unity). There's already a huge tear in the consistency; however, the top right all houses applications that do not quit on close. Why make an exception to the music player? Should my chat client close when I'm not talking to anyone? I believe this behavior is further bludgeoning a hole in a consistent and predictable desktop experience. Close and Minimize are basicallly the same in Unity, except that some applications quit upon close: their main windows will take longer to load up again, when the launcher is clicked. Some applications are services. A service should not quit upon close, especially not, when its indicator is meant to be a proxy to the app's functions. Examples for this are Broadcast Streams (Gwibber), Telepathy Connection Managers (Mission Control 5 / Empathy) and EDS (appointments, tasks). Whether Rhythmbox|Banshee fits into this category remains to be seen. I personally think if you pick a gimmick you should either ditch it once you see it's useless or you should roll with it confidently. Sound Menu transport controls are cool, they are a selling point for Ubuntu, we should back them up with a default music library manager as e.g. Banshee, which should never quit. Banshee should be a service. The Sound Menu Spec also offers an interface to starting up the default music library manager's playback by pressing the MPRIS play button in the Sound Menu. This would mean, if Banshee supported being started by an MPRIS play command from the Sound Menu, the transport controls in the Sound Menu will always be present, regardless if Banshee is running or not. Adding other apps to the sound menu might seem politicallly correct or
