[FZH] Window controls for GNOME 3

Tommy He lovenemesis在fedoraproject.org
星期三 二月 23 13:37:33 UTC 2011



如果 GNOME Shell 实现了多窗口自动平铺(看样子的确是的),那么最大化最小化的确是无用的东西,去掉吧!

On Wed, Feb 23, 2011 at 7:23 PM, microcai <microcai at fedoraproject.org> wrote:
> 我用的就是 git 版本的 gnome-shell , 怎么没发现变了?
> 2011/2/23 Yu Chen <jcomee at gmail.com>:
>> 今天的gnome-shell已经把窗体标题栏上最大最小化按钮去掉了,看样子又开始打口水仗了。
>> 2011/2/23 Yu Chen <jcomee at gmail.com>:
>>> ---------- Forwarded message ----------
>>> From: Owen Taylor <otaylor at redhat.com>
>>> Date: 2011/2/23
>>> Subject: Window controls for GNOME 3
>>> To: gnome-shell-list at gnome.org
>>> OK, I promised Jon McCann to write a mail here giving information on
>>> my thoughts on removing the minimize and maximize buttons since I've
>>> been resisting the request of the designers to remove these buttons.
>>> My main objection to removing them has been that I didn't think we
>>> really understood the use case for minimization, or how we would
>>> satisfy that use case. The pattern of use for minimization is that a
>>> lot of people don't use minimization at all, and other people use it
>>> extensively.
>>> It didn't make sense to me to remove something that we don't
>>> understand with idea that we'd add it back later if it turned out to
>>> be needed. To make people suffer, and have it be a major focus of the
>>> GNOME 3 transition, then go and add it back anyways.
>>> On the other hand, if we do have a reasonable sense that we have
>>> workflows that basically will work for everybody, then I'm more
>>> comfortable removing minimization. So, this mail is reporting on my
>>> attempt to come to a better understanding of minimization and how it
>>> fits in with the GNOME 3 workflow.
>>> Why do people minimize windows?
>>> ===============================
>>> I think the first thing to realize is that minimization doesn't make
>>> sense if you maximize everything. If you run everything maximized,
>>> then it just doesn't enter in ... switching between windows is
>>> switching between windows. (I personally typically maximize
>>> everything, so I don't minimize windows.)
>>> Reasons people minimize:
>>>  * Because they like a tidy desktop. I think a lot of people are
>>> uncomfortable with a desktop where the window the are working with is
>>> overlapping other windows - where they are looking at a "gigantic pile
>>> of papers". These people like working with a few windows on a clean
>>> desktop. But they still have a larger set of windows open for less
>>> immediate tasks.
>>>  * Because maximized windows interact badly with unmaximized windows.
>>> If I have a task that involves looking at multiple unmaximized
>>> windows, then I switch to a maximized web browser, getting back to the
>>> other state is hard - I have to select each window in turn without
>>> accidentally selecting the maximized window again.
>>>  * To find a window behind other windows - if you generally select
>>> windows by clicking on them, and can't see the window or windows want,
>>> minimization can be a way of getting a big or maximized window out of
>>> the way and working with the windows underneath.
>>>  * To "save windows for later" - if you open windows to represent
>>> tasks, like responding to an email or reading a PDF of a paper, you
>>> might not want them directly in your face interfering with the work
>>> you are doing first.
>>> Are workspaces a replacement for minimization?
>>> ==============================================
>>> Since minimization is basically about wanting to work with a subset of
>>> windows, workspaces are clearly related to them. As compared to
>>> minimization they have advantages and disadvantages. The advantage is
>>> that they are stable - that is, I can have one workspace with a
>>> terminal and an editor, and another workspace with a web browser and
>>> my mail program and they will always stay that way - I won't lose the
>>> grouping. The disadvantage is that it isn't flexible - if I need the
>>> editor and web browser open at once then I have to go to the
>>> Activities Overview and move the web browser, and then my web browser
>>> and mail program can't be open at once until I move it back.
>>> Experiences with removing the minimize button
>>> =============================================
>>> I asked the two people on the Red Hat GNOME Shell team who I knew
>>> heavily used the minimize button to try removing it and report back to
>>> me about their experiences. (These obviously are not typical users
>>> using typical applications, but they provide some data about how
>>> people actually use the minimize button.)
>>>  Marina:
>>>   Marina generally used the minimize button when switching between a) coding
>>>   on the shell with non-maximized terminal and editor windows b) doing tasks
>>>   in a maximized web browser. She would minimize the web browser
>>>   to get from a) to b) and then use the overview to get back to the minimized
>>>   web browser.
>>>   When she turned off the minimize button, she was initially very frustrated
>>>   because she kept going to where the minimize button was but finding only
>>>   the "useless" close button there. She then turned off the close button as
>>>   well and was much happier with the result. [I don't think this is
>>>   really an option however - there are going to be too many cases where apps
>>>   are designed expecting a close button.]
>>>   No problems were reported with:
>>>   - Having the maximized web browser window still visible under the coding
>>>     windows... this was reported to not be distracting.
>>>   - Having to separately activate the editor and terminal windows from
>>>     the overview.
>>>   Workspaces were found not to be useful because they didn't allow to
>>>   easily switch between working with a fullscreen webbrowser, to
>>>   using a non-full-screen web browser in conjunction with an editor for
>>>   patch review.
>>>  Dan:
>>>   Dan normally keeps xchat, terminal, and emacs in a fixed layout,
>>>   and then uses unminimization and minimization to temporarily switch
>>>   from the terminal/emacs task to mail or web browser tasks.
>>>   He also uses minimization to save web pages opened for patch reviews
>>>   for doing later.
>>>   Dan reported that he was able to successfully switch to a setup
>>>   where web browser and email were on separate desktops. He didn't feel
>>>   it was an improvement, but he also didn't feel a strong urge to
>>>   go back to the previous setup. He did report feeling isolated when
>>>   on a workspace with only web or only email.
>>>   Dan often opens links in separate web browser windows, so to do the
>>>   patch review tasks that frustrated Marina's use of workspaces, he would
>>>   open the review link from email in a separate window and then move
>>>   that window to his coding window.
>>>   He found after using it for a while that the most effective way
>>>   to save windows for later use was to reserve a desktop for that
>>>   and move windows to be saved to that desktop.
>>> Problems with current minimization
>>> ==================================
>>>  * Many people (most people?) never minimize. So one of the most
>>> prominent permanent controls is something that has no particular
>>> function but makes your window vanish if hit accidentally.
>>>  * There is no real mental model for what happens when hiding. The
>>> window shrinks off to the corner, but when you go back to the
>>> overview, it's still there and looks the same as if you hadn't hid it.
>>>  * The minimize icon is a remnant of the GNOME 2 taskbar and has
>>> nothing to do with the GNOME 3 experience. (Really, we don't have
>>> minimization at all, we have "hiding")
>>>  * Having minimize and maximize controls puts "stress" on the concept
>>> of the centered title - the titlebar looks unbalanced.
>>>  * If people are using minimization within GNOME Shell as an
>>> alternative to things that could be done with workspaces, then we have
>>> to design other components for two different workflows - the
>>> minimization workflow and the workspaces workflow.
>>>  * Minimized windows break the illusion of zooming to the overview.
>>> Is removing the button really removing minimization?
>>> ====================================================
>>> You can still minimize with:
>>>  - Right click on titlebar to get to the window menu
>>>  - Alt-right click on window contents to the window menu
>>>  - Alt-F9
>>>  - Alt-space n
>>> But, no, for all real purposes removing the button is removing minimization.
>>> Could we design an improved "hiding" model
>>> ==========================================
>>> I think there are some things we could do that would make minimization
>>> less weird.
>>>  - Maybe use a different icon
>>>  - Reserve a space for minimized windows in the overview - perhaps
>>> something like:
>>>    +--------+ +-------+
>>>    |        | |       |
>>>    +--------+ +-------+
>>>        +---------+
>>>        |         +
>>>        +---------+
>>>      +---+ +---+ +--+
>>>      |   | |   | |  |
>>>      +---- +---+ +--+
>>>   So then the other windows would smoothly animate to their overview
>>> positions and
>>>   the minimized windows would just "be there" in the overview.
>>>  - Animate minimized windows toward the reserved space instead of
>>> towards the corner
>>>   (we could even show the minimized windows on the background of the root window
>>>   in the main view and return back to the days of twm???)
>>> But at this point, we're out of time to experiment with anything for
>>> GNOME 3.0. Also this doesn't address minimization being unused by many
>>> users and having two different workflows for working with a subset of
>>> windows.
>>> The maximize button
>>> ===================
>>> The above was about minimization - but the request was also to remove
>>> the maximize button. This is a little different since there are more
>>> obvious ways to maximize a window - the drag to the top gesture or
>>> double-clicking on the title bar - we're not really talking about
>>> removing the feature of maximization but just the button.
>>> I don't think it's generally a big deal to remove the maximize button.
>>> Trying it myself, I did find one problematical area - it's pretty hard
>>> to distinguish between a mostly maximized and maximized window but
>>> they behave quite differently. I think there are some adjustments we
>>> could make to help with that - one one in particular is making sure
>>> when you unmaximize we actually shrink the window by a significant
>>> amount and don't leave it screen sized.
>>> The way forward
>>> ===============
>>> I'm going to openly admit here that I'm a bit uncertain.
>>> Until we got the new workspaces controls, removing the minimize button
>>> was impossible; it took away a workflow, and left only a very hard to
>>> use alternative. With a better model for working with workspaces,
>>> there is evidence it might work, but we're working from a very limited
>>> data set and we don't have much runway left to adjust before GNOME
>>> 3.0.
>>> Other considerations against removing window controls: no minimize
>>> leaves us further away from Mac and Windows and removing the minimize
>>> button in the fallback mode would work much less well, since the
>>> overview isn't available to quickly and conveniently switch to a
>>> hidden window.
>>> On the other hand, if we leave minimization, we have something that is
>>> clearly undesigned and unfinished. And we portray the taskbar as
>>> something that is missing rather than something that is unneeded,
>>> because we have a window hiding icon that was designed for minimizing
>>> to the taskbar.
>>> In the end, I think with GNOME 3 we need to emphasize design coherency
>>> and slickness - what is different and better, and that actually is
>>> more important than being 100% sure we perfectly meet everybody's
>>> workflow. Having half-designed minimization is going against the goal
>>> of coherency. And doesn't provide testing of alternate workflows. So
>>> I'm going to remove the minimize and maximize buttons for GNOME 3.0,
>>> and if it doesn't work out, we'll eat crow, design window hiding
>>> right, and add it back for 3.2.
>>> Feedback?
>>> =========
>>> If people want to give their thoughts here, that's fine, but I don't
>>> think a mailing list debate is the best way to come to a decision, so
>>> the decision above should be considered basically final for the 3.0
>>> release.
>>> The real form of feedback that we need going from GNOME 3.0 to 3.2 is
>>> careful observation of how users are using GNOME 3 - are they figuring
>>> out how to use the overview and workspaces and message tray as we
>>> expect them to use them, or are they doing cumbersome workarounds
>>> because we took away essential features.
>>> - Owen
>>> _______________________________________________
>>> gnome-shell-list mailing list
>>> gnome-shell-list at gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>>> --
>>> Yu
>> --
>> Yu
>> _______________________________________________
>> Chinese mailing list
>> Chinese at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/chinese
> _______________________________________________
> Chinese mailing list
> Chinese at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/chinese

Take a Deep Breath out of Windows


关于邮件列表 Chinese 的更多信息