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

[Dylan McCall <dylanmccall@xxxxxxxxx>]

> 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