On Tue, May 18, 2010 at 23:40, Jan Claeys <[email protected]> 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
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : [email protected] Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
