Evan wrote: > On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall <dylanmcc...@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 -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
