Re: Gnome shell suggestions after a bit of usage

[Florian Max <florian muellner gmail com>]

2011/7/7 Dylan McCall <dylanmccall gmail com>

Just like the Minimize and Maximize buttons, the close button refers
to a window, not an application (which can have many windows).

Correct.

<nitpick mode>
  Though the expected action is to close the corresponding window, not
  withdraw it from X (Rhythmbox) or minimize it (Empathy).
</nitpick mode>

Closing a window might result in an application deciding to exit, but ideally
that is invisible to the user (and it just about always is already).
The only thing that matters — and the only thing we have ever actively
expressed to end users — is that the window goes away.

Here I disagree. You are describing  MacOS' behavior here, GNOME has pretty much since forever used the "closing the last window exists the application" model Windows uses. Feel free to argue that we should adapt Mac policy, but don't pretend that deviating from the usual model was consistent.

For ordering an application to Quit you usually have an option in the
application itself, and there's the Application menu in the top bar.

Correct, but that's beside the point - the availability elsewhere is no excuse for inconsistency. (And there are some sympathies on the design side for mpt's "crusade" against quit)

 

In the case of music players, Ubuntu for example has been patching
music players to remove the explicit Quit option, making it so they
will quit if they aren't doing anything (music is not playing). I'm
not sure where that is upstream.

Nowhere as far as I know, like pretty much all of Canonical's recent design efforts. Which is unfortunate, as I neither feel like tracing downstream patches for a large number of modules, nor like replacing $distro_of_choice with Ubuntu, so I don't have any first-person experience with any of those.

But back on topic. The inconsistency of "Music Players" behaving differently from other applications aside, this approach requires at least consistency between "Music Players" to work well - Canonical is in a much stronger position here, as they can patch *all* music players they distribute (which, "power user" features as PPAs and compilation from source aside, should be good enough for the vast majority of their user base). For GNOME it would be pretty much impossible to provide the same level of consistency - huge effort would have to be spend to convince other upstream projects to support "the GNOME way". Yes, being upstream can suck - sometimes :-)

The music player status icon is a big one: it's there when the rhythmbox process is
running, even though the rest of GNOME only cares that the application
has a visible window.

True, unfortunately. Which is why, in general, status icons are considered legacy in GNOME 3 - in GNOME 2, the (ab)use of status icons by Rhythmbox, Empathy, Transmission et al. was "just" violating the HIG, but now it really clashes with some important assumptions. Currently the design advice is to not use status icons when running in GNOME 3, at some point this may be enforced by not displaying them at all (as far as I know, Canonical did this already (in favor of their "app indicators"), but again, downstream is in a stronger position here to push forward a change like this).

Florian