Re: Window controls for GNOME 3
Hi! * To hide a window in which a background task is ongoing. Minimizing the window allows the user to monitor the progress in the window list button (assuming progress is shown in the title bar, which ought to be the case), and to be alerted when the task has either finished or encountered a problem (when the window list button flashes), without being distracted by the window itself. Which is clearly what notification are for and not the window title. I think this case is solved in a much nicer way in the shell than it was before. Might be that some applications need updates though. How would an application show the continuous progress of a background task using notifications, or the messaging tray in general? I don't see anything in the shell design docs that suggest that would be a good way to do it. (I guess you could show a progress bar or something when you roll over a notification icon, but that's not very helpful.) Well, IMHO I want to be alerted mostly when it finishes or when it has a problem and that's what notification are for. If I want to know the exact progress, that's an active action where I can look into the window or check the message tray. I agree. As for progress: a message tray icon that subsumes longrunning 'progress' (file) operations (copy, move, delete, download; maybe update, install, for packages/applications; ...) with ability to cancel, pause, restart? Wasn't this planned anyway? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
Hi! I agree. As for progress: a message tray icon that subsumes longrunning 'progress' (file) operations (copy, move, delete, download; maybe update, install, for packages/applications; ...) with ability to cancel, pause, restart? Wasn't this planned anyway? Some work has been done but is has to be finished and picked up in the shell: https://ssickert.wordpress.com/2010/05/09/introducing-my-gsoc%C2%A0project/ Regards, Johannes ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Fri, 2011-03-04 at 12:57 +0100, Jürgen Mangler wrote: I agree. As for progress: a message tray icon that subsumes longrunning 'progress' (file) operations (copy, move, delete, download; maybe update, install, for packages/applications; ...) with ability to cancel, pause, restart? Wasn't this planned anyway? KDE 4 has something like this, I believe. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Friday, 04 March, 2011 11:42 PM, Adam Williamson wrote: I agree. As for progress: a message tray icon that subsumes longrunning 'progress' (file) operations (copy, move, delete, download; maybe update, install, for packages/applications; ...) with ability to cancel, pause, restart? Wasn't this planned anyway? KDE 4 has something like this, I believe. (KDE4)Yes it does... In GNOME Shell, it might defeat the purpose of hiding the tray by default. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 23 Feb 2011, at 00:21, Owen Taylor wrote: Why do people minimize windows? === I'd also add to your list: * To hide a window in which a background task is ongoing. Minimizing the window allows the user to monitor the progress in the window list button (assuming progress is shown in the title bar, which ought to be the case), and to be alerted when the task has either finished or encountered a problem (when the window list button flashes), without being distracted by the window itself. Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd. mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 1 Mar 2011, at 21:36, William Jon McCann wrote: I don't have any plans to drop the symbolic close button but some successful designs have done this already. WebOS uses a close gesture and no on screen explicit controls. iOS on iPad mostly does away will all forms of window management but in some cases (secondary windows) uses a Done button instead of the symbolic version. Most secondary windows in GNOME 2.x were never supposed to have a symbolic close button anyway (at least from the HIG/usability team's POV), because for those windows where there's a choice of dismissal options, it's not clear whether closing the window that way means 'OK' or 'Cancel', for example. For many years I was told it was a metacity bug that we couldn't hide it altogether, but I don't know whether that was eventually fixed -- I haven't chased it up for a while :) Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd. mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
Hi! * To hide a window in which a background task is ongoing. Minimizing the window allows the user to monitor the progress in the window list button (assuming progress is shown in the title bar, which ought to be the case), and to be alerted when the task has either finished or encountered a problem (when the window list button flashes), without being distracted by the window itself. Which is clearly what notification are for and not the window title. I think this case is solved in a much nicer way in the shell than it was before. Might be that some applications need updates though. Regards, Johannes ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 3 Mar 2011, at 14:14, Johannes Schmid wrote: Hi! * To hide a window in which a background task is ongoing. Minimizing the window allows the user to monitor the progress in the window list button (assuming progress is shown in the title bar, which ought to be the case), and to be alerted when the task has either finished or encountered a problem (when the window list button flashes), without being distracted by the window itself. Which is clearly what notification are for and not the window title. I think this case is solved in a much nicer way in the shell than it was before. Might be that some applications need updates though. How would an application show the continuous progress of a background task using notifications, or the messaging tray in general? I don't see anything in the shell design docs that suggest that would be a good way to do it. (I guess you could show a progress bar or something when you roll over a notification icon, but that's not very helpful.) Cheeri, Calum. -- CALUM BENSON, Interaction Designer Oracle Corporation Ireland Ltd. mailto:calum.ben...@oracle.com Solaris Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Oracle Corp. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
Am 02.03.2011 12:14, schrieb Vishnoo: Why does one actually want to maximize and restore windows or resize them? (nautilus windows dont count, lets think about apps/task instead of file-management ;p ) IMO, the maximize/resize 'feature' is a workaround for a window management that never got fully implemented. It would be very interesting to know why user is forced to resize the windows manually and try to fix those problems. For example while trying to store knowledge in my brain, I often have pdfs with exercise opened and maximize the window to have it easily readable while working on plain ol' paper. When I do actual coding (and dont have the 2nd monitor available), I often have the exercise next to the IDE which requires the windows to be resized properly. 50/50 splitting wouldn't help since I'd want to set the distribution of screen real estate dynamically. Regardless of the fact that evince comes up with a completely unusable window dimension here, I often need to adjust the size of the content displayed. Marcel ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, 2011-03-02 at 19:49 +0100, Gendre Sebastien wrote: Le mercredi 02 mars 2011 à 10:15 -0800, Adam Williamson a écrit : Oh god, no. How does a text editor 'know' how big a window 'needs' to be to display a 500 page document (or a 10,000 line source code file)? It can't fit on one screen. I like to have it in a full-screen window at 1680x1050. I know people who think I'm insane and think you should never display text more than 80 characters wide as it's 'unreadable'. Am I right? Are they right? Which of us would you like this new intelligent window manager to piss off? That's just the first case that springs to mind. Terminals, as Thomas points out, are another good one. Browsers; again, it comes down to text flow. I like a full-screen browser window, lots of people think this makes lines of text way too wide. Neither of us is correct or incorrect. (sorry if I feed the troll...) If the window size can be adapted to its content, it should be smart. If the window adapted is than the available size on the display, it will adapt itself to the available size. But that only makes me happy. It doesn't make the people who think a full-screen window is too big to read text on happy. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, 2011-03-02 at 10:15 -0800, Adam Williamson wrote: On Wed, 2011-03-02 at 16:44 +0530, Vishnoo wrote: IMO, the maximize/resize 'feature' is a workaround for a window management that never got fully implemented. It would be very interesting to know why user is forced to resize the windows manually and try to fix those problems. In an ideal world there should be no need for maximize/restore. App should be able to know the size that displayed-content requires to display, notifies the window manager and the window resizes accordingly. Oh god, no. How does a text editor 'know' how big a window 'needs' to be to display a 500 page document (or a 10,000 line source code file)? It can't fit on one screen. You are reading/understanding things too literally. If there are 500/5000 lines of code it obviously necessitates to display the lines as several pages. It can not be *legibly* displayed in a single page view. Let me rephrase that more clearly, When I said In an ideal world there should be no need for maximize/restore , it just meant we should not _have_ to do window resize often. I'm *not* suggesting the removal of the ability to resize and that everything be done only automatically. There are always special cases, on desktop/laptops, where we would like to resize manually. Some of the cases mentioned earlier could be dealt with better tiling/grid views, but some wont work with improving grid view alone. But, IMO, this outcry for removal of the maximize button seems a very disproportionate to the actual need and does not focus on the cause of the problem which requires user to resize often. If we were to restore the maximize button, it would not be the right solution, it would only be a workaround. -- Cheers, Vish ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Thu, 2011-03-03 at 00:55 +0530, Vishnoo wrote: You are reading/understanding things too literally. Let me rephrase that more clearly, When I said In an ideal world there should be no need for maximize/restore , it just meant we should not _have_ to do window resize often. I'm *not* suggesting the removal of the ability to resize and that everything be done only automatically. Well, you didn't say I was supposed to understand them metaphorically. =) But if all you're saying is that GNOME should try to be smarter about initial sizes (and, possibly, dynamic resizing/tiling) so that manual resizing becomes less necessary, sure, I can get all the way behind that. I was just worried about the idea of taking it to its 'logical extension' - your 'ideal world' scenario where manual maximizing / resizing become unnecessary. If we're not going there, then no problem, go ahead. But, IMO, this outcry for removal of the maximize button seems a very disproportionate to the actual need and does not focus on the cause of the problem which requires user to resize often. If we were to restore the maximize button, it would not be the right solution, it would only be a workaround. I'm not hugely bothered either way about the maximize button, personally. You only have to learn 'double-click on the window bar' once and it's just as easy as clicking a maximize button. As a general principle, the removal of features with _no easy alternative_ bothers me much more than the removal of one of many different ways to do something, as long as one of the other ways is not inherently more difficult. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, Mar 2, 2011 at 4:01 PM, Akshay Dua aks...@cs.pdx.edu wrote: I don't know what started the rash that caused the itch to remove those buttons, but its causing everyone to talk negatively about the shell, while otherwise no one would have even cared if they remained there. Am I wrong? Are there people truly bothered by seeing the minimize button in the title bar? The goal of Gnome Shell is not to uphold the status quo. Gnome Shell is a test bed to experiment with a new paradigm in UI design. It is going to be different than what you are used to. -- http://exolucere.ca ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
I am OK with or without buttons, but surely, you don't mean that stable desktop interfaces released to production environments should be a test bed, do you? I would assume that a test bed consists of a volunteer group of beta testers that fill out usability surveys (which I will be more than happy to do for the shell), but I am not sure that a stable release should work as a test bed. It should probably try to maximize popularity and keep focus on new and important features. -- Akshay http://web.cecs.pdx.edu/~akshay/ On Wed, Mar 2, 2011 at 3:22 PM, Robert Park rbp...@exolucere.ca wrote: On Wed, Mar 2, 2011 at 4:01 PM, Akshay Dua aks...@cs.pdx.edu wrote: I don't know what started the rash that caused the itch to remove those buttons, but its causing everyone to talk negatively about the shell, while otherwise no one would have even cared if they remained there. Am I wrong? Are there people truly bothered by seeing the minimize button in the title bar? The goal of Gnome Shell is not to uphold the status quo. Gnome Shell is a test bed to experiment with a new paradigm in UI design. It is going to be different than what you are used to. -- http://exolucere.ca ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Thursday, 03 March, 2011 02:15 AM, Adam Williamson wrote: In an ideal world there should be no need for maximize/restore. App should be able to know the size that displayed-content requires to display, notifies the window manager and the window resizes accordingly. Oh god, no. Agree. You would be adding the auto maximizing / restoring headaches not only to window manager devs but to application developers and users as well!!! ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
(What happened to your mail client line-wrapping settings?) On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com wrote: 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 generally applaud the bold changes happening in the shell, but I disagree with removing the maximize/restore button. I'll paste here a comment I wrote on Allan's blog: 1) Drag-and-drop is very difficult on touchpads, and most people these days are buying laptops. Drag-and-drop is also undiscoverable. 2) Double-clicking the title-bar is undiscoverable. Conclusion: maximize/restore button should remain. Too me, it's a simple as that. I don't think the cleanliness of removing the button is worth the UX trade-off. Getting rid of the minimize button is great, though! Thanks, Sandy ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Tue, 2011-03-01 at 07:54 -0800, Sandy Armstrong wrote: (What happened to your mail client line-wrapping settings?) On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com wrote: 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 generally applaud the bold changes happening in the shell, but I disagree with removing the maximize/restore button. I'll paste here a comment I wrote on Allan's blog: 1) Drag-and-drop is very difficult on touchpads, and most people these days are buying laptops. Drag-and-drop is also undiscoverable. 2) Double-clicking the title-bar is undiscoverable. I agree with these reasons. May I also add one more - double clicking is terrible. Firstly, I always opt for single click (recovering RSI/OOS). Secondly, how many computer users *still* have no idea what double clicking does; the kind of people who double click on *everything*, links in websites, menus, buttons, or keep double clicking on applications while waiting for them to start. Admittedly it is usually windows users who I observe doing this, but I think it is wrong to assume that users; a) know that double click exists b) can actually distinguish that it is different from single click I would prefer the approach of 'one foot in the old and one in the new'. maximize for the old, dragging for the new. I still know windows 7 users who don't use aero snap, so keeping maximize not only retains familiarity for them, but current gnome2 users too. John ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
Hey Sandy, On Tue, Mar 1, 2011 at 10:54 AM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: (What happened to your mail client line-wrapping settings?) On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com wrote: 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 generally applaud the bold changes happening in the shell, but I disagree with removing the maximize/restore button. I'll paste here a comment I wrote on Allan's blog: 1) Drag-and-drop is very difficult on touchpads, and most people these days are buying laptops. Drag-and-drop is also undiscoverable. That depends a lot on the quality of the touchpad too... With a crappy touchpad (and there are a lot of them) it is arguably harder to aim precisely to hit a small button than dragging a large object (titlebar) to a Fittsian infinite edge (top of screen). This is made worse when the maximize button is immediately adjacent to a button that is as opposite in effect as you can get. Two bits of badness converge here. The first is that the cost of a slip in aiming and clicking is unreasonably large. There is no undo for window close. It is definitely not what you wanted to happen. It is relatively difficult to recover from. And in some cases may result in data loss. In every case it results in intense frustration (argh-ing). We don't want the user to ever feel that. The second is the stress involved in aiming at a small target which is intensified by a known cost of a slip. It makes you think. The interface ideally should not interrupt you and draw that kind of attention to itself. These issues were always present in classic window management but become highly problematic with many touch interfaces and especially so with low precision pointing devices. There are three other things that should help in these cases: * using the entire titlebar as a double click target to maximize * using keyboard shortcuts for maximization * in some cases maximizing certain sovereign apps by default (particularly on smaller screens) 2) Double-clicking the title-bar is undiscoverable. Honestly, I think discoverability is one of the more misused critiques of user interface design. There are a lot of reasons for this and I won't cover them. I don't think that discoverability is a prerequisite for a successful interface. Surely, in many cases it helps. But it is just one factor. Gestures (especially touch) aren't discoverable and yet they are extremely useful and powerful. Context menus aren't discoverable and yet they provide a way to access lots of functionality that couldn't otherwise be presented in the visible and discoverable interface. Keyboard shortcuts obviously aren't discoverable most of the time. As you mention above, drag and drop of any kind is not discoverable and yet it has formed the basis of many very successful designs. Discoverability almost always involves learning. You are not born knowing what the _ icon in every window means. Nor do you intrinsically know what maximize means. You learned it at some point. Another trend you are seeing is a bit of a drift away from symbolic representation and indirect action to more tactile direct manipulation. I think this is natural. It feels better somehow. And if it just does that thing I don't need to know the name for that thing. When I throw a window at the top of the screen it gets bigger. I wanted it to get bigger. Cool. I don't have to even know the word for it in tech speak is maximize or know that it is symbolically represented by a square. I don't have any plans to drop the symbolic close button but some successful designs have done this already. WebOS uses a close gesture and no on screen explicit controls. iOS on iPad mostly does away will all forms of window management but in some cases (secondary windows) uses a Done button instead of the symbolic version. To summarize, discoverability is only one of the considerations in designing a successful interface. In this case, it wasn't the most important factor. But if you simply cannot get used to life without the maximize button, despite the benefits, or using one of the other approaches mentioned above, feel free to add the button back using the settings. Hope that helps a bit. Jon ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
2011/3/1 John Stowers john.stowers.li...@gmail.com: Admittedly it is usually windows users who I observe doing this, but I think it is wrong to assume that users; a) know that double click exists b) can actually distinguish that it is different from single click Not to mention, trackpads are double click unfriendly. -- Un saludo, Alberto Ruiz ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 03/01/2011 03:52 PM, Alberto Ruiz wrote: 2011/3/1 John Stowersjohn.stowers.li...@gmail.com: Admittedly it is usually windows users who I observe doing this, but I think it is wrong to assume that users; a) know that double click exists b) can actually distinguish that it is different from single click Not to mention, trackpads are double click unfriendly. Last I checked, virtually every device with a trackpad has some sort of physical mouse button for this very purpose (laptops and whatnot). ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Tue, Mar 1, 2011 at 7:35 PM, Ryan Peters slosh...@sbcglobal.net wrote: Last I checked, virtually every device with a trackpad has some sort of physical mouse button for this very purpose (laptops and whatnot). O RLY? http://www.google.ca/images?q=buttonless%20trackpadoe=utf-8rls=org.mozilla:en-US:officialclient=firefox-aum=1ie=UTF-8source=ogsa=Nhl=entab=wibiw=1671bih=945 -- http://exolucere.ca ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Do, 2011-02-24 at 20:58 -0500, Marina Zhurakhinskaya wrote: There are some apps where using the quit button won't make sense. Terminals being the foremost one. I believe for gnome-terminal they are still using the same factory so a quit on terminal it remove all terminals, right? For that, there could be a Close Window option in the application menu. In any case, this is just some idea that I wanted to put out there for designers. Seemed to work for me, but it's up to designers to decide if it fits in with the overall experience. The 'close'-button might well be THE single attribute you expect any window to have; if there's a window you expect to be able to close this window. Also it would be pretty inconsistent if there's a close-button in the overview when there is none in the worspace view. The whole idea of substituting a straightforward, in-your-face obvious way of closing a window by an action that is more complicated and whose discoverabilty is dubious to say the least, seems quite unmotivated. There is simply no compelling reason for this change and lots of good reasons against it. It seems more like an attempt at finding a justfication for the existence of the application menu in the top bar - which is currently lacking. Greets, Chris ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Fri, Feb 25, 2011 at 8:56 AM, Christian Jäger
christian.jae...@rub.de wrote:
The 'close'-button might well be THE single attribute you expect any
window to have; if there's a window you expect to be able to close this
window. Also it would be pretty inconsistent if there's a close-button
in the overview when there is none in the worspace view.
Agreed. I'm all for experimenting with new ideas, but the close button
MUST stay. Minimize I never use except by accident so I am happy to
see it go. Maximize I do use, but I'm happy with things like double
clicking the titlebar, if it means less clutter on the titlebar, but
every app and every window needs an easy and immediate method to close
it, and there can't possibly be anything better than the existing
close button.
The more I think about my previous suggestion ('hide on new workspace'
button at left and close button at right), the more I like it. It's
because both actions will result in the window disappearing, but the
buttons are far apart, so there's no chance to accidentally hit one
when you meant the other.
The whole idea of substituting a straightforward, in-your-face obvious
way of closing a window by an action that is more complicated and whose
discoverabilty is dubious to say the least, seems quite unmotivated.
There is simply no compelling reason for this change and lots of good
reasons against it. It seems more like an attempt at finding a
justfication for the existence of the application menu in the top bar -
which is currently lacking.
The application menu will grow in importance as apps increasingly add
support for it. I like the idea of it a lot because it means one
unique space that never moves where you can always find a menu for the
app that you're using. But you're right, it's currently
under-utilized.
--
http://exolucere.ca
___
gnome-shell-list mailing list
gnome-shell-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 25/02/11 01:46 PM, Robert Park wrote: Agreed. I'm all for experimenting with new ideas, but the close button MUST stay. Minimize I never use except by accident so I am happy to see it go. Maximize I do use, but I'm happy with things like double clicking the titlebar, if it means less clutter on the titlebar, but every app and every window needs an easy and immediate method to close it, and there can't possibly be anything better than the existing close button. I could say exactly the same about the minimize button, that there needs to be a way to quickly make a window get out of my sight. On the balance of things, I use minimize more than close, by a long shot. --Pat ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Fri, Feb 25, 2011 at 12:20 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: So out of curiosity, what sort of tasks do both you and Robert do if you don't mind me being nosy? Oh, ok. Well, I'm an app developer and I have two physical displays. Before I got the second display (nearly 10 years ago now) I was a heavy user of workspaces, but since getting the second screen, I have literally never once used more than one virtual workspace. My typical workflow is like this: left screen contains a maximized gedit window, right screen contains maximized firefox window. Both will be open with many tabs at any given time (firefox displaying API reference docs, and gedit editing various files for my current project). Any non-maximized window, such as empathy chat window or a terminal or whatever, goes onto the left screen. I never, ever need to minimize anything because if there's ever anything that I don't want to look at, I just bring gedit to the front and everything else disappears. Also, I should mention that the bottom 20% of my gedit window is a terminal (thanks to gedit-plugins), but I also frequently have a couple other terminals open as well. The terminal inside gedit is used almost exclusively for launching my app (and running it's test suite), while the other terminal windows are for compiling (so they can be easily hidden behind gedit). Typically also my terminal windows will be tabbed, because I'll start a long compile going in one, then open a new tab to do something else, and then whenever I do something that takes more than 30 seconds to complete I start a new tab in order to continue working. Hope that makes sense. ;-) In terms of the overall vision of the new Gnome Shell, I'm really enamored with it. I've *always* thought of the taskbar as something clunky and I'm glad to see it go. Way way back before I could afford a computer capable of running GNOME, I used to really like the Blackbox WM (I'm talking GNOME 1.x days here). I'm a minimalist and I like things to be as simple as possible. Blackbox has no taskbar and no minimize button! Funny how we've come full circle with that ;-) -- http://exolucere.ca ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Feb 25, 2011, at 16:33, Robert Park wrote: Oh, ok. Well, I'm an app developer and I have two physical displays. Before I got the second display (nearly 10 years ago now) I was a heavy user of workspaces, but since getting the second screen, I have literally never once used more than one virtual workspace. My typical workflow is like this: left screen contains a maximized gedit window, right screen contains maximized firefox window. Both will be open with many tabs at any given time (firefox displaying API reference docs, and gedit editing various files for my current project). Any non-maximized window, such as empathy chat window or a terminal or whatever, goes onto the left screen. I never, ever need to minimize anything because if there's ever anything that I don't want to look at, I just bring gedit to the front and everything else disappears. Funny how we both use workspaces the same way, and both do essentially the same task, but have exactly different uses of the minimize button. I think my values simply come from always having enjoyed and liked the spatially-oriented desktop. I was very sad when two events happened in GNOME: 1) Nautilus switched away from spatial-by-default 2) Nautilus stopped supporting homedir as desktop I thought those were both fantastic ways to go, but it explains why I like to be able to manipulate the clutter on my desktop rather than simplify it into more group/task-oriented windows. --Pat PS: Love the photography. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Fri, Feb 25, 2011 at 3:05 PM, Pat Suwalski p...@suwalski.net wrote: Funny how we both use workspaces the same way, and both do essentially the same task, but have exactly different uses of the minimize button. That is odd, isn't it! Whenever I want to hide something I always think in terms of putting something in front of it, either the big gedit window or a new tab. I think my values simply come from always having enjoyed and liked the spatially-oriented desktop. I was very sad when two events happened in GNOME: 1) Nautilus switched away from spatial-by-default 2) Nautilus stopped supporting homedir as desktop I thought those were both fantastic ways to go, but it explains why I like to be able to manipulate the clutter on my desktop rather than simplify it into more group/task-oriented windows. Ah yeah, I remember being excited about the idea of the spatial nautilus before it came out, but not actually liking it in practise, but I can't remember why. PS: Love the photography. Thanks! It's something I'm passionate about. -- http://exolucere.ca ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote: While the close operation is common, it's not frequent, and therefore might not require visual representation on-screen all the time. Huh, I use the Close button pretty frequently. I guess I'm still scarred from when Esc didn't work in every dialog by default. Both the application menu in the top bar and the close buttons in the overview are well discoverable. Right now, the application menu has one Quit option, and the user actually needs to make a decision whether they want to fully quit the application with all its windows before going for that option. Having both Quit and Close Window (if applicable) options in that menu would inform the user of the choice they have and allow to use that feature as the central way of closing a window or an application. My main problem with removing the Close button is a combination of things: - The Close button is relevant to a single window. It's nicely *in* the window right now. Your proposal would put it far away from the window (thus losing context), and would make it not immediately visible (you'd need to open the app menu first - probably discoverable, as you say, but far from obvious). My experience with non-technical users (say, my wife) is that if they don't see something on the screen, they won't know that that something is actually available. - The Close button is the get me out of here safety exit. You wouldn't remove the Back button on a browser just because you can also access it from the menus. Federico ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Thu, Feb 24, 2011 at 11:31 AM, Federico Mena Quintero feder...@gnome.org wrote: On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote: While the close operation is common, it's not frequent, and therefore might not require visual representation on-screen all the time. Huh, I use the Close button pretty frequently. I guess I'm still scarred from when Esc didn't work in every dialog by default. Me too. I don't do file-quit since it's a lot easier to access the close button. But not all apps behave the same unfortunately. Both the application menu in the top bar and the close buttons in the overview are well discoverable. Right now, the application menu has one Quit option, and the user actually needs to make a decision whether they want to fully quit the application with all its windows before going for that option. Having both Quit and Close Window (if applicable) options in that menu would inform the user of the choice they have and allow to use that feature as the central way of closing a window or an application. My main problem with removing the Close button is a combination of things: - The Close button is relevant to a single window. It's nicely *in* the window right now. Your proposal would put it far away from the window (thus losing context), and would make it not immediately visible (you'd need to open the app menu first - probably discoverable, as you say, but far from obvious). My experience with non-technical users (say, my wife) is that if they don't see something on the screen, they won't know that that something is actually available. There are some apps where using the quit button won't make sense. Terminals being the foremost one. I believe for gnome-terminal they are still using the same factory so a quit on terminal it remove all terminals, right? As a new user I think I would feel pretty intimidated if I got a bunch of windows that didn't have a close button. It would require some training for them to use the other method because just about every other UI out there uses a close button and is an established UI. Combined with the fact that there are exceptions like the terminal, I think that would lead to some confusion. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, 2011-02-23 at 16:34 -0500, Marina Zhurakhinskaya wrote: While the close operation is common, it's not frequent, and therefore might not require visual representation on-screen all the time. Huh, I use the Close button pretty frequently. I guess I'm still scarred from when Esc didn't work in every dialog by default. Me too. I don't do file-quit since it's a lot easier to access the close button. But not all apps behave the same unfortunately. I meant that you only need to close things a handful of times per session, not that you would use a different way to do that if there is a close button. You mostly would close the applications/windows that you open for temporary use, but you won't close most of the windows you have open throughout the session. There are some apps where using the quit button won't make sense. Terminals being the foremost one. I believe for gnome-terminal they are still using the same factory so a quit on terminal it remove all terminals, right? For that, there could be a Close Window option in the application menu. In any case, this is just some idea that I wanted to put out there for designers. Seemed to work for me, but it's up to designers to decide if it fits in with the overall experience. Marina ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, Feb 23, 2011 at 10:03 AM, Frederik scumm_fr...@gmx.net wrote: No minimising does not mean that everything is maximised. You can maximise a window by dragging it to the top (or by double-clicking) and de-maximise it by dragging it from the top (or by double-clicking). That does make sense. I'll really have to install the F15 Beta soon to check this out in more detail. So there won't be any way to minimise windows at all then? Not saying this is a bad idea, I'm just trying to get the facts straight. :) Fab ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 02/23/2011 01:21 AM, Owen Taylor wrote: My main objection to removing them has been that I didn't think we really understood the use case for minimization My two use cases are: * Removing distracting clutter out of sight (e.g. terminal with compilation process) Ok, I can move it to another workspace. It's just a little bit more pointing and dragging action. * Accessing an icon on the desktop (usually via minimise all / show desktop, but sometimes also by clicking minimise buttons) I understand that the desktop icons will go away. But then I need a replacement place where I can quickly access the documents that I work on during a week. The current state is confusing: desktop hardly accessible but no replacement in the sense of a quickly accessible document working set buffer. Best regards Frederik ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
Hi! I understand that the desktop icons will go away. But then I need a replacement place where I can quickly access the documents that I work on during a week. The current state is confusing: desktop hardly accessible but no replacement in the sense of a quickly accessible document working set buffer. Well this goes a bit off-topic the window control issue but the concept[1] of finding and reminding is simply not yet implemented in 3.0. Should be in 3.2 hopefully though. Regards, Johannes [1]http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
Le mardi 22 février 2011 à 19:21 -0500, Owen Taylor a écrit : 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 This is just a personal analisys based what I have based on what I have seen since 5 years. Maximize The usage of maximize depends to the display size and resolution. If you have a screen 14, you maximize the majority of windows and keep some windows not maximize like Empathy IM, Gnome Terminal, etc. But If you have a screen 20, you maximize only one or two windows like Inkscape or Anjuta but not maximize the majority of windows. You just adpat the size of the window to this own content. To summarize, more the screen is little, more you will maximize and vice versa. And why you maximize? To see more content in a window. So I wonder if it's not better to don't maximize beside the screen but beside the window content (like in Mac OS X). And about maximise to focus on work: That depends on people. Some will mazimiser the window on which they work and some do not need it. Minimize to panel = The use of this feature depends to the use of maximise. In Gnome 2 (or in other OS), why people use minimize to panel? For hide the window. So if the majority of windows are maximized, user don't need to minimize the window to panel for hide it. But if the majority of windows are not maximized, user really need to minimize the window to panel for hide it. On Gnome Shell, we don't have a panel but we have a dash. So, I think we can have a Minimize to or a simply hide window feature. If user hide a window, it don't appears in the desktop and in the windows section on Activites overview but only on the Dash. Button == Keep buttons would not be bad for the newcomers, they would not be lost. Buttons Hide and Close are needed, but maximize button is just for don't lost newcommers. -- Gendre Sebastien ko...@romandie.com signature.asc Description: This is a digitally signed message part ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On 02/23/2011 03:53 AM, Fabian A. Scherschel wrote: On Wed, Feb 23, 2011 at 10:03 AM, Frederik scumm_fr...@gmx.net mailto:scumm_fr...@gmx.net wrote: No minimising does not mean that everything is maximised. You can maximise a window by dragging it to the top (or by double-clicking) and de-maximise it by dragging it from the top (or by double-clicking). That does make sense. I'll really have to install the F15 Beta soon to check this out in more detail. So there won't be any way to minimise windows at all then? Not saying this is a bad idea, I'm just trying to get the facts straight. :) Fab ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list You can minimize windows by right-clicking the title bar, ALT+F9, ALT+SPACE and then N, or changing your preferences to include a minimize button. If I remember correctly, you can still add and remove and move around buttons at your leisure, though I'm not sure what benefits they would bring. The reason they're hiding the minimize function isn't because its useless, but because it's been mostly deprecated now that Shell has an infinite list of workspaces that you can drag and drop windows on to. If there's a better way to implement minimization or hiding windows, it should be implemented around 3.2 or 3.4. By the way, removing the close button by default, while some people might like it, I don't really understand. It reduces visual clutter, yes, but I don't want to have to go to the activities overview just to close a tiny window, you know? Otherwise, I completely agree with the decision to remove those two buttons and I can't wait until GNOME Shell is released as stable! :) - Ryan Peters ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, 2011-02-23 at 12:07 +0100, Johannes Schmid wrote: Well this goes a bit off-topic the window control issue but the concept[1] of finding and reminding is simply not yet implemented in 3.0. Should be in 3.2 hopefully though. You can see this work-in-progress here: http://people.gnome.org/~federico/news-2011-02.html#zeitgeist-in-gnome-shell This week I'm working on having a functional journal after the work in the Zeitgeist hackfest. Federico ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
[ Quoting Federico Mena Quintero in Re: Window controls for GNOME 3... ] It's like saying, well, we could show the current window's title next to the Activities button, and since you can already move windows with Alt-drag, we can remove titlebars altogether :) yes please! Have been using a one-pixel-wide window decoration for a few years now. Love it. grtz Miek signature.asc Description: Digital signature ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, Feb 23, 2011 at 12:20 AM, Sriram Ramkrishna s...@ramkrishna.me wrote: Now, as I understand it the work around would be to move this to another workspace. To do that would require a number of window management steps that I previous accomplished using a single button action. What if there was a titlebar button that moved the window to a new workspace? I think that would probably be the best of both worlds. The people who want a 'minimize' button are provided with a single button that makes the unwanted window disappear, but instead of relying on the outdated taskbar metaphor, it fits into the 'new' workspace metaphor that Gnome Shell is aiming towards. This would be a natural fit for the Activities display, because now there's no difference between 'hidden/minimized' windows and any other workspace. There doesn't need to be a designated area for hidden windows, because they're all just on other workspaces, which there is already a good interface for. Owen mentioned the titlebar being 'off balance' because of the title being at center and all three buttons off to one side, so how about this: [-]Window Title[X] So that's the 'hide to new workspace' button at left, and close button at right, with title centered. Nice and balanced, eh? What does everybody think? ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, Feb 23, 2011 at 13:23, Robert Park rbp...@exolucere.ca wrote: [-]Window Title[X] So that's the 'hide to new workspace' button at left, and close button at right, with title centered. Nice and balanced, eh? What does everybody think? Initial reaction is that you've reintroduced a screen element that is analogous to the old workspace switcher applet in the GNOME 2 panel: it can be hit by a user who has no idea what a workspace is and who suddenly finds their window missing without any idea how to get it back. But maybe with the right level of animation it could be made clear. Not sure. ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
On Wed, Feb 23, 2011 at 12:30 PM, Jason D. Clinton m...@jasonclinton.com wrote: Initial reaction is that you've reintroduced a screen element that is analogous to the old workspace switcher applet in the GNOME 2 panel: it can be hit by a user who has no idea what a workspace is and who suddenly finds their window missing without any idea how to get it back. Ok, but currently with there being a minimize button with no taskbar, we are already in a situation where users can hit a button and not know how to get their window back. I'm simply proposing we adapt the concept of the 'minimize' button to work with workspaces. Either way, the user has to go to the activities menu to find their window again, but with my suggestion there's now a designated area for hidden windows, and the UI for it is completely consistent with the existing workspaces, because it is just another workspace ;-) But maybe with the right level of animation it could be made clear. Not sure. Well, it could animate into the upper left corner, where the 'Activities' button is. Then users will go there looking for it and they will find the workspaces. -- http://exolucere.ca ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
While the close operation is common, it's not frequent, and therefore might not require visual representation on-screen all the time. Similar reason to why we don't want to have application launchers on screen all the time. Both the application menu in the top bar and the close buttons in the overview are well discoverable. Right now, the application menu has one Quit option, and the user actually needs to make a decision whether they want to fully quit the application with all its windows before going for that option. Having both Quit and Close Window (if applicable) options in that menu would inform the user of the choice they have and allow to use that feature as the central way of closing a window or an application. It's a menu that is visible in the desktop view, so it's more of 1.5 step operation with a click - move to the option you want - release. So the goal would be removing a full UI concept and centralizing the options related to the operation in another existing part of UI. That would make the application menu more functional, inform the user better, reduce redundant options, AND make for a sleeker look :). Marina - Original Message - From: Federico Mena Quintero feder...@gnome.org To: Marina Zhurakhinskaya mari...@redhat.com Cc: gnome-shell-list@gnome.org Sent: Wednesday, February 23, 2011 11:12:41 AM Subject: Re: Window controls for GNOME 3 On Tue, 2011-02-22 at 21:48 -0500, Marina Zhurakhinskaya wrote: We've added two other ways for closing windows/applications in GNOME 3: a per-window close icon in the overview and a quit option in the application menu. The only thing that is missing is the UI ability to close an individual window from the desktop view. I mostly used the Quit option in the application menu for closing single instance applications, such as calculator or gconf-editor, but I had to remember to go to the overview if I wanted to close a Firefox Downloads window or an individual gedit window I no longer needed. Be careful with this line of thinking. You are replacing a one-step, common operation with a two-step one that is not immediately discoverable. It's like saying, well, we could show the current window's title next to the Activities button, and since you can already move windows with Alt-drag, we can remove titlebars altogether :) In general, sleek looks just for the sake of sleek looks are not good. Things have to be comfortable to use. A knife's handle has an awkward shape, but the bump in the front is so your hand doesn't slip forward and you get cut; the bump in the back is so you can pull out the knife easily; the bump in the center is to accomodate the inside of your palm. A knife with a sleek, cylindrical handle wouldn't be very nice to use. Federico ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: Window controls for GNOME 3
As Owen described, I found it relatively easy to change my workflow to not use minimization. It does make more sense to use a positive action for switching to a different window I want, rather than a negative action of minimizing and then seeing what I have in front of me. I found it very useful to remove the close button as well. I originally did that to wean myself off going for the minimize button and not finding it there, but I'm also wondering whether we can get rid of this one-of icon completely. We've added two other ways for closing windows/applications in GNOME 3: a per-window close icon in the overview and a quit option in the application menu. The only thing that is missing is the UI ability to close an individual window from the desktop view. I mostly used the Quit option in the application menu for closing single instance applications, such as calculator or gconf-editor, but I had to remember to go to the overview if I wanted to close a Firefox Downloads window or an individual gedit window I no longer needed. I think having a second option Close Window in the application menu if the application has multiple windows would solve this problem and allow us to get rid of the visual clutter of a lone close icon in the titlebar. If anyone wants to try it out without the close icon in the titlebar, just run ' gconftool-2 -s -t string /desktop/gnome/shell/windows/button_layout ' and restart gnome-shell. Marina - Original Message - From: Owen Taylor otay...@redhat.com To: gnome-shell-list@gnome.org Sent: Tuesday, February 22, 2011 7:21:08 PM Subject: Window controls for GNOME 3 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
Re: Window controls for GNOME 3
On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor otay...@redhat.com wrote: 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 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 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. Hi Owen, my two cents. I'm still going through the process of seeing how much pain it is for not having minimizing. The first instance of wanting to minimize something is when I have a terminal that is scrolling debug messages and I'm not interested in its contents at the moment. I really want to move it out of my sight. I'm not exactly interested in the window unless something broken has happened. I would probably say the same if I'm on a web browser that is on Pandora or last.fm or some such web page that has dynamic content that I'm not really interested in looking at because I'm using it as a service but it's using real estate that is distracting me. Now, as I understand it the work around would be to move this to another workspace. To do that would require a number of window management steps that I previous accomplished using a single button action. The other option is to use a key combination. Now admittedly, things like scrolling texts in terminals could be argued as expert mode and one could expect that a key combination for those people should be sufficient. But I'm not sure of the pandora or last.fm type thing. Other than that I haven't really felt an urge to minimize anything. sri ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
