Thoughts on quitting and window controls

Evan eapache at
Fri Apr 9 23:17:45 UTC 2010

On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall <dylanmccall at> wrote:
> On Tue, Apr 6, 2010 at 8:39 PM, Jonathan Blackhall
> < at> wrote:
>> It's very confusing for me when I click the big 'X' in my window controls,
>> only to find that the application I was attempting to close has since been
>> minimized to my system try (or notification area or its respective indicator
>> applet or wherever it goes instead of quitting).  Examples of programs with
>> this behavior include Rhythmbox and Empathy in the default install.  To me,
>> the 'X' signifies closing and quitting the application.  If I wanted to
>> minimize it and keep it open, I would think to click the 'Minimize' button
>> before clicking the 'X'.  In fact, I'd argue that the only reason anyone
>> thinks this is appropriate is because it's what's been done in the past.
>> The reason I find this so frustrating is because in order for me to eXit an
>> application, I have to go searching through menus (File->Quit) or know some
>> fancy keyboard shortcuts (things that casual users never even think about).
>> I can only assume that developers' theories behind this (which is definitely
>> not a problem unique to Ubuntu) stem from them telling themselves that no
>> one would actually want to Quit their application.  "What they *really* mean
>> to do is close the window, but keep the application running silently.  So
>> I'll just save them the trouble of accidentally quitting by changing the
>> function of that 'X' button."  I just dislike the fact that it sends mixed
>> signals.  After all, if I click 'X' in Firefox or in gEdit or in a whole
>> host of other applications, I'm quitting and completely closing it.  Why
>> must this be different in Rhythmbox?  And also, when I install a new
>> application, what is the 'X' going to do when I click it in this
>> application?
>> I'm not exactly sure what I'd propose to fix this problem.  I really just
>> think that the current way is broken.  Maybe the function could be switched
>> to the Minimize button, but that would likewise exhibit ambiguity, although
>> I'd argue less so than the current incarnation.  Maybe there should be a new
>> window button, but that doesn't seem like a very elegant solution either.  I
>> thought about filing this as a bug, but then I thought it might be better to
>> generate discussion amongst developers.  What are your thoughts?  Do you
>> consider the current situation a problem? If so, what do you propose to fix
>> it?
>> Cheers,
>> Jonathan
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at
>> Modify settings or unsubscribe at:
> I chewed on this thought for a bit, and I think adding a "really
> close" button to a window would compromise what is _potentially_ a
> pretty well thought out bit of UI. That's not to say it is well
> thought out yet, but I think it could be!
> Conventionally, a window represents some thing the user is doing, so
> closing it should close that thing. A toplevel window is almost always
> something the user has directly triggered and is directly,
> purposefully interacting with, and I don't think we have anything else
> in the desktop that fits that role. Therefore, if the act of closing a
> window is affecting anything more than what that window is
> representing, something has gone wrong and should be fixed. For most
> web browsers, we're fine; the close button closes the web page
> associated with that window, but the application, other web pages and
> any current downloads (should) keep running.
> The rest is naturally fed by the “Just Works” philosophy; if a process
> is not providing anything, it should become irrelevant (probably by
> exiting). Firefox does this for you all the time. A lot of developers
> think of it as a robotic "all window are closed, so exit" deal, but I
> think it's more "we are no longer serving a purpose, so exit."
> Applications should track what they are doing for the user to decide
> whether they are wasting memory.
> Windows are remote controls for resources. In the case of Tomboy,
> that's a note. (When you close a window in Tomboy, you aren't
> destroying the note!). For Empathy, that's an instant messaging
> account (Telepathy). When you close the buddy list, it doesn't log you
> out, but you can open the buddy list and tell it to log you out. (In
> this case that's technically the case, too; Telepathy, Empathy, etc.
> are split into a whole pile of small, detached programs that run for
> different purposes).
> Rhythmbox is a different example, but let's try to fit it under the
> same theory. It already mostly does. The Rhythmbox main window is for
> controlling what music the Rhythmbox "service" (represented by its
> indicator icon) is playing. It just happens that the Rhythmbox service
> is, technically, the same process as the Rhythmbox main window. Users
> don't care about that, though.
> Someone opens Rhythmbox to control the playing music (to pause it or
> play it), then closes it when that is done and the service goes on in
> the background. If the music is stopped and Rhythmbox's controller is
> closed, Rhythmbox has no reason to continue running, so the process
> should exit. That should have absolutely no impact on the surrounding
> user interface, however.
> The Problem: that does have a strange impact on the surrounding user
> interface. Particularly strange for Rhythmbox, since the indicator
> serves as a launcher for the controller. Unless we want that Rhythmbox
> indicator to be permanent, it always will create a bizarrely
> shape-shifting desktop within the current design. It always will with
> a "really close" button, too, because "really closing" the window will
> kill the Rhythmbox service and, therefore, the indicator applet.
> Consider the inconsistency at hand from a lower level: killing the
> Rhythmbox process kills its indicator, its controller, and the music.
> Killing the Empathy process kills the buddy list but maintains your
> accounts  as they are and the message indicator. Killing Evolution
> does not delete your email (unless you were having a good day; it gets
> jealous).
> Good news, in my books: gnome-shell has launchers and running
> applications in the same place ;)
> That is a more profound improvement than mere cosmetics. It means
> things don't move unexpectedly. Personally, I want to be able to
> reliably head to wherever I start applications and open my Buddy List,
> unconcerned with whether a process called "empathy" was already
> running, and I want to do that as quickly as heading to the message
> indicator and opening my Buddy List from it. I want to do that because
> the same functionality fits for anything, not just instant messaging;
> from notes to music to calendars and todo lists.
> We can either have a specialized launcher in the top panel for every
> single type of desktop service, or we can have a smarter application
> launcher.
> Take care,
> Dylan
> PS: Granted, my chewing on this was in the midst of a billion things
> happening at once, so I realize I may be coming across as a complete
> lunatic.

Mind-boggling: yes. Lunatic: not necessarily :)

If I'm understanding you properly, the user should have no concept of
services or processes. There is a single list of all applications,
whether they are running with a window, running as a service, or not
running at all.
When the user clicks on an application which is not running, or
running as a service, then the control window for that application
opens on top. When all of an application's windows are closed, then
the process closes (as long as no services are running). If a service
is running as well, it is responsible for garbage-collecting itself
when it is no longer doing anything (ie when rhythmbox is no longer
playing music). When a service process exits like this, the UI
shouldn't change at all - the user shouldn't even know.

The only question I have right now about this model is the action
which occurs when an app with a window already open is clicked on in
the list. In the current windowing model, you can focus the existing
window (via the task bar) or open a second window (via the menu). With
the integrated application list, how do we nicely handle both of these
use cases?


More information about the Ubuntu-devel-discuss mailing list