Thoughts on quitting and window controls

[Derek Broughton]

Evan wrote:

> On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall <dylanmccall at gmail.com>
> wrote:

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

I think you've both answered my concerns pretty well.  I agree that users 
don't generally have (or want to) a concept of "services".  I like the idea 
that "launching" can open a window for an existing service, or a brand new 
app.  Is there really a need to distinguish between focusing an existing 
window and opening a new one?  In the case where only one window for an app 
_can_ exist, it's irrelevant.  Where more than one window could exist, 
there's usually an option within the existing window to do so.  Shouldn't 
that be enough?
-- 
derek