unity-design team mailing list archive

[Frederik Nnaji <frederik.nnaji@xxxxxxxxx>]

On Tue, May 18, 2010 at 23:40, Jan Claeys <lists@xxxxxxx> wrote:

> 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.
>

i say go with what Mark suggested[1] - to use seperate designs for the two
cases:
* perhaps a hollow red circle on the button for "hide window"
* the red button with the X for "close & quit"

The WM only needs to know, if the app is about to quit upon click, or not,
in order to draw the correct frame.

[1] https://lists.launchpad.net/ayatana/msg02181.html