← Back to team overview

unity-design team mailing list archive

Re: Window close button is not consistent

 

Op maandag 17-05-2010 om 14:06 uur [tijdzone -0500], schreef Dieki N:
> Currently, the close button in the window decoration closes the
> window, and in most cases closes the application if the last window is
> closed. However, on applications such as Rhythmbox, Empathy, or
> Gwibber, it closes the last window, but leaves the application
> running. For these applications, not closing is a necessary part of
> their functionality, but it's pretty annoying for the user since the
> close button is not consistent. 

To me personally "close button" == "close window" has been how things
worked since the 1980s, so it's entirely consistent (for me).  ;)

> Does anyone else believe this to be a problem?

I think the main problem is that people might not associate the window
with the indicator which shows status for the program that is running in
the background.  Maybe the sound indicator should temporarily change
shape or color when the user presses the "play" button?

> One possible solution to this would be to change the "close" icon to a
> "minimize to AppIndicator\MessagingMenu\SoundMenu\Whatever" icon if
> the application signals that it doesn't use the normal behavior of the
> close button. This would make the close button be consistent, and also
> has the advantage that WM's\themes that don't support it would be no
> worse off than they are now.

You aren't "minimizing" the window, you are closing it; the indicator
has been there all the time.

> Another possible solution would be to add a "minimize to <whatever>"
> button to the window if signaled, but keep the close button there. The
> close button would behave as normal and exit the application, but the
> minimize to tray button would fulfill the functionality the
> application needs of closing the window but not the application.

Exiting the application when the window close button is pressed is *not*
"normal", it depends entirely on what application, what window, what
other windows are open and several other complex factors (also think
about the Run dialog, gnome-do, gnome-keyring, etc.).

The fact that Rhythmbox, Banshee, etc. are monolithic application that
implement both the song selection window and the background playing is
just an implementation detail IMO, and it shouldn't be exposed to the
user.  If you look at XMMS2 for example, you'll see they did actually
split those two functionalities in two separate programs, and thus
according to your theory an xmms2-client should have a close button
while rhythmbox should have a minimize-to-indicator button, even if you
would expect the same behaviour in both cases.

Another examples is where opening multiple documents might open one
application in one case and multiple applications in another case.
Again, that's an implementation detail you don't want to expose to the
user by providing different "close" buttons.


-- 
Jan Claeys




Follow ups

References