|
On 02/07/2011 02:25 PM, Dylan McCall wrote: 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).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 CornwallI 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 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. As for Android, it's an interesting concept but I wonder about its effectiveness in a non-portable environment. -- -Brett Cornwall BrettCornwall@xxxxxxxxx |