Giovanni, Thanks for taking the time to respond. I appreciate it and I know that following and participating in these threads is often distracting and no conducive to getting real work done.
On Mon, Jun 20, 2011 at 12:15 PM, Giovanni Campagna < [email protected]> wrote: > Il giorno lun, 20/06/2011 alle 10.20 -0400, Jesse Hutton ha scritto: > > It's a little puzzling to me why GNOME Shell has deprecated window > > minimization, given that one of its primary design goals is to enable > > "distraction-free computing." > > > > > > The purpose of minimizing a window is precisely to remove it as a > > distraction from the current focus. Leaving the window open, but > > letting it be obscured by other windows pertinent the user's current > > work creates more distraction, not less, and clearly goes against the > > distraction-free goal. Moving the unwanted window to another workspace > > is also less than optimal. It causes more work for the user than > > simply clicking a minimize button. Indeed, it's hard to imagine > > something simpler than clicking a button on the window frame. Once > > "minimized" in the fashion of moving it to a new workspace, it is also > > more work to retrieve the window. You have to navigate to the > > workspace, look at the window, navigate back, etc. So, both actions, > > removing a window from the current focus and returning it to the > > current focus (when a user wants to check on it) seem less natural > > when using workspaces as a minimization solution. > > I think the designers' rationale is: either the window is part of your > current task, so it should be open for fast retrieval and switch, or it > is not, and therefore should be on a different workspace. > I understand that thinking and working in terms of tasks is a bit > problematic at first, expecially given that this concept overlaps with > that of applications, windows and workspaces, as you sometimes have apps > that hosts multiple tasks (eg. web browser), more than one maximized > window per task (eg. email client + composer), more than one workspace > per task (eg. primary workspace + secondary monitor). > Nonetheless, I think this, and all the necessary behavioral shifts, > should be kept in mind when discussing current gnome-shell design on > task / window / app management. > My main point of contention with that rational is that not all windows are part of any particular task for a user. Would a music player be part of a specific task? What about an instant messenger or IRC client? Even for email, I can easily think of use cases where you would want to associate the application with a given task in one instance (maybe you're communicating with somebody about a particular project), and then a different one in another. In other words, the use cases for email span a larger scope than a single task. > > > > > It also conceptually doesn't make sense on a couple levels. First of > > all, some apps simply don't fit into the "activity" model where they > > occupy the primary focus of the user. Examples have already been > > given, ie Evolution, Rhythmbox, Banshee, Empathy, etc. They are meant > > to run in the background to some extent. So, applying the single > > notion of activity to them doesn't work well. Second, a workspace for > > windows that you don't want to see normally doesn't seem to really be > > a "workspace" at all. A workspace by its very nature is a collection > > of apps that represent a task or a project, or really whatever a user > > wants the relation to be. The common and indelible quality of it, > > however, is that is where *work* is done. So, using this notion as a > > bucket for apps that you don't want to focus is rather awkward, IMO, > > as it doesn't really represent a place where work is done anymore. > > Again, a workspace for background, long running apps is the 3.0 > workaround. For 3.2, a better solution is being developed (minimization > to dash AppIcon), plus those apps are expected to leverage resident > libnotify notifications (like rhythmbox does at the moment). > I'm happy to learn that such a solution is being implemented. I think it's a fairly natural way to handle it, and somewhat already understood and tested by users, since it will resemble OSX's behavior. My next question is how does this impact the story being told that minimizing has been deprecated and removed from GNOME Shell? Clearly, if an implementation for handling minimized window state is being worked on, it is not the case that it has been deprecated. Much of the discussion here has been about the removal of the minimize button, and not even the absence of a "place" where minimized windows go (since they appear in overview mode, anyway). Are the designers reconsidering the inclusion of that minimize button? Or is any other function/action to minimize being considered? > > > > > All that said, I would really appreciate it if some of the designers > > and developers who are *actually* working on solving problems for > > GNOME Shell would participate in discussions like this. I understand > > if they are actually busy getting work done, but they would hopefully > > be able to elevate the dialog from (paraphrasing) "show me some data > > that our design is flawed" and "I would never want to do that" (and > > thus nobody else should). > > I agree that the response of some of the developers (including myself) > is not helpful at times, but I hope you understand that following the > reasoning and the arguments of all gnome-shell-list threads is > impossible. > We (or I, at least) try to do our best to provide the users with the > best possible experience, which I think you agree cannot be obtained by > merely summing up all the various proposals and rants which are > periodically raised on the list, as those who are ok with current > behavior have no reason to post (except occasionally for defending the > devs), and anyway the majority of gnome user base doesn't even know that > there is a gnome-shell-list. > On the other hand, bugzilla is much more followed, so if you think you > have a concrete proposal (detailed enough that a developer could turn it > into a patch), that solves a real problem and does not contradict the > core principles (not too much, at least), don't hesitate to open a bug. > But not for abstract "problems" (or perceived so): in that case, you > need to talk with the designers at #gnome-design. > > Giovanni > > I have no doubt that anyone who sincerely works on GNOME wants to provide users with the best possible experience -- for whatever value of best they have. And, I'm certainly appreciative of that effort (and would even love to join it, in earnest). I also understand that bugzilla is a a natural place for developers to track issues and have discussions about issues. However, it doesn't seem like an best platform to get a good idea of what discussions are currently taking place and to try to participate. For example, is there a bug that documents the 3.2 minimize-to-dash feature and the current thinking on minimization in general? (I looked but either bugzilla's search sucks, or I just don't know how to use it). Jesse
_______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
