[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] Regarding the Sound Menu Spec's closing of inactive audio applications





On 02/07/2011 05:17 PM, frederik.nnaji@xxxxxxxxx wrote:
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 democratic, but has imo no greater relevance to the feature.

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?
-- 
-Brett Cornwall