On Thu, Apr 8, 2010 at 7:57 PM, Dylan McCall <dylanmcc...@gmail.com> wrote: > On Tue, Apr 6, 2010 at 8:39 PM, Jonathan Blackhall > <johnny.one....@gmail.com> 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@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> >> > > 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? Cheers, Evan -- 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
