unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

Hi Brett,

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.