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. > > 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). > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part