On Mon, Feb 7, 2011 at 20:47, Brett Cornwall
<brettcornwall@xxxxxxxxx> wrote:
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 democratic, but has imo no greater relevance to the feature.