On Fri, Apr 9, 2010 at 8:40 PM, Derek Broughton <de...@pointerstop.ca> wrote: > 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?
Possibly. You make a valid point that certain apps (like rhythmbox) should never need more than one control window. However, apps like OpenOffice and Firefox often use more than one open window. Whlie both of these do have an internal option to create a new window, some subset of users (including myself) is likely accustomed to using the menu entries in the gnome menu to create new windows. Since the option still exists, it's not necessarily a bad thing (there is no technical loss of functionality). We just have to be careful we don't confuse users who are used to being able to eg use Applications->Office->OpenOffice Word Processor to not just open a new window, but actually create a new blank document. I know that if I upgraded and wasn't aware of the new method, this could get quite frustrating quite quickly. In short, it isn't really the design that's a problem, it's the upgrade path from the current design that could confuse a lot of people. Just something to be aware of. 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
