Re: Window controls for GNOME 3
On Tue, Feb 22, 2011 at 4:21 PM, Owen Taylor 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
GNOME Shell 2.91.90 released
GNOME Shell 2.91.90 is now available at: http://ftp.gnome.org/pub/GNOME/sources/gnome-shell/2.91 0cb01d1b9cdd060883a88fab9377b8c4498ac24a967c5135e6ab6c05f598e332 gnome-shell-2.91.90.tar.bz2 20e41afe1e1528856d158663a5ff4aa08feddc66d3861ecc1ce55ea44867f991 gnome-shell-2.91.90.tar.gz This release just about concludes user interface changes anticipated before GNOME 3.0. The only significant change we expect after this release is to add a native network indicator based on NetworkManager 0.9. About GNOME Shell = GNOME Shell provides core user interface functions for the GNOME 3 desktop, like switching to windows and launching applications. GNOME Shell takes advantage of the capabilities of modern graphics hardware and introduces innovative user interface concepts to provide a visually attractive and easy to use experience. Tarball releases are provided largely for distributions to build packages. If you are interested in building GNOME Shell from source, we would recommend building from version control using the build script described at: http://live.gnome.org/GnomeShell Not only will that give you the very latest version of this rapidly changing project, it will be much easier than get GNOME Shell and its dependencies to build from tarballs. Changes since 2.91.6 * Workspace handling [Owen, Jakub] - Replace existing workspace controls in the overview with a vertical list of workspace thumbnails. - Change workspace orientationin the main view to vertical - Workspaces are automatically managed - empty workspaces are removed, other than the last workspace which is always empty - a new workspace is added when something is started on that workspace. - Add ability to change workspace by mousewheel scrolling over thumbnails [Sardem FF7] * Add a PolicyKit authentication agent; requests to the user for authentication from PolicyKit now show up as shell-themed dialogs. [David] (http://davidz25.blogspot.com/2011/02/gnome-3-authorization.html) * Visual refresh [Florian] - Improve the appearance and behavior of the overview "dash" - Use larger icons in the Application browser - Improve the appearance of the top panel and round the corners of the screen [Florian] - Improve the appearance of the search entry in the overview [Florian, Ray] * Remove minimize and maximize buttons from the titlebar [Owen] (http://www.mail-archive.com/gnome-shell-list@gnome.org/msg02527.html) * Change the options for stopping the system; Suspend is now in the menu, while Power Off... is hidden, but can be accessed by holding down Alt when browsing the user status menu [Ray] * Port telepathy integration to telepathy-glib from hand-written D-Bus code [Guillaume, Morten] * Remove the window filtering and highlighting when using the dash application menu - it was confusing and buggy rather than helpful [Adel] * Use the alt-tab switcher when Above_Tab (alt-` typically) is pressed, and fix keybinding handling durng alt-tab. [Rui] * Message tray - Improve the expand/collapse behavior of for greater stability [Marina] - Hold notifications while the user is marked busy [Giovanni] - Group chat messages together [Hellyna] - Fix bug that resulted in missing icons for contacts without avatars [Hellyna] - Enable navigation using arrow keys between buttons in notifications [Hellyna] * Add audio feedback when scrolling over the volume status icon [Giovanni] * Add a "Show Layout" item to the input source selector menu [Giovanni, Sergei] * Use GLib application launching API, to allow us to associate windows with applications in a broader rannge of circumstances [Colin] * Unify history management between run dialog and looking glass, giving consistent behavior [Jasper] * Pass extension metadata object to extensions so they can be configured in metadata.json [Giovanni] * Support symbolic colors for legacy tray icons [Dan] * Shell Toolkit: implement ability to specify inset shadows in CSS [Florian] * Remove no-longer-useful --xephyr option from gnome-shell wrapper script [Dan] * Improve the drawing of the "box pointer" used for menus and notifications [Sardem FF7] * Memory leak fixes [Maxim] * Code cleanups [Adel, Dan, Florian, Marina] * Bug fixes [Adel, Bastien, Dan, Florian, Giovanni, Jasper, Marina, Maxim, Owen, Ray, Takao] * Build fixes [Dan, Jason, Jasper, Luca, Owen, Florian, Pierre, Thomas] * Visual tweaks [Florian, Jon McCann, Jonathan S, Luca, Marina] Contributors: Giovanni Campagna, Jason D. Clinton, Guillaume Desmottes, Maxim Ermilov, Luca Ferretti, "Sardem FF7", Takao Fujiwara, Adel Gadllah, Rui Matos, Morten Mjelva, Florian Müllner, Hellyna Ng, Bastien Nocera, Jonathan Strander, Ray Strode, Jasper St. Pierre, Owen Taylor, Sergey V. Udaltsov, Colin Walters, Dan Winship, Thomas Wood, Pierre Yager, David Zeuthen, Marina Zhurakhinskaya Design: Alan Day, Wil
Mutter 2.91.90 released
Mutter 2.91.90 is now available at: http://ftp.gnome.org/pub/GNOME/sources/mutter/2.91/ aa10cb7caeae48ecea1903cbdd13d13cdf1b173b4c79684beaa451e4583d01ea mutter-2.91.90.tar.bz2 2b01cb58d97aff31c2f36a3046ee741b9844b0bfcbce7324c826a9d66e026ff8 mutter-2.91.90.tar.gz About Mutter Mutter is a window and compositing manager that displays and manages your desktop via OpenGL. Mutter combines a sophisticated display engine using the Clutter toolkit with solid window-management logic inherited from the Metacity window manager. While Mutter can be used stand-alone, it is primarily intended to be used as the display core of a larger system such as GNOME Shell. For this reason, Mutter is very extensible via plugins, which are used both to add fancy visual effects and to rework the window management behaviors to meet the needs of the environment. Changes since 2.91.6 * Change Above_Tab from being a cycle_group binding to a switch_group binding [Rui] * Make plugin-loading failure fatal [Colin] * Add 'position-changed' signal to MetaWindowActor [Owen] * When 'live_hidden_previews' is enabled, position hidden windows to allow the creation of workspace previews [Owen] * Fix bug with opacity of MetaBackgroundActor Contributors: Rui Matos, Owen Taylor, Colin Walters Translations: Jorge González [es], Mattias Põldaru [et], Sweta Kothari [gu], Luca Ferretti [it], Changwoo Ryu [ko], Nguyễn Thái Ngọc Duy [vi] Bugs fixed: 641309 When live_hidden_previews is set, force placement for hidden windows 641310 MetaWindowActor: Add a 'positioned-changed' signal 641979 Visual glitch on workspace selector closing overview mode 641384 Make plugin loading failure fatal 642426 Don't pass handled key events to GTK+ ___ 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" 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 can't be
Application categories
So, in addition to the window controls, the other tiny code change with a large controversial impact that is sitting around as we come to the GNOME 3 UI freeze is the question of the category filters the Application browser. https://bugzilla.gnome.org/show_bug.cgi?id=638271 The designer request is to remove categories, and the obvious advantage of removing categories is that we fit more application icons on the screen at once because we no longer have the categories taking up screen space. But I'm skeptical that we can get the number of applications for the average GNOME 3.0 down to the point where we don't have a scrollbar and instant recognition is possible. And when you aren't in that regime, having more space for the icons just means that you have a more intimidating sea of icons. With the current number of applications that our users will have, categories are an effective tool for finding many applications... an effective way of cutting down from more than you can instant recognize in to a number you can instant recognize in. So, we're going to stick with application categories for now. If in the future we are more effectively managing the set of applications that are pre-installed, then we can consider dropping predefined categories. - Owen (We do need to remove some of the excess horizontal space in the application browser - there's considerably more than is necessary and I think we could fit an extra icon horizontally at many resolutions.) ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
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 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 brows
Re: Faenza-Dark not showing correct icons in shell panel
Il giorno mar, 22/02/2011 alle 22.21 +0100, Marcel ha scritto: > Moin, > > I'm using the Faenza-Dark icon theme, the Faenza variant for dark panel > backgrounds which contains light panel icons. GS still shows the dark > panel icons (from Faenza-Light which is in the same package, -Dark > inherits -Light) on it's dark panel, so they're barely visible. > > In #gnome-shell, one told me that there's something wrong with the svg > images since they're being recolored (?) by GS. I want to ask the theme > author to fix this, but what exactly should be done for the icons to be > shown properly? I.e. what should I ask him to do? > > Marcel I am using Faenza as well. When I used the dark variant I had to link some light icons (or delete some, I can't remember) since they were missing (or they were not *light*, can't remember again). The main point with Faenza is, as far as I know, that the theme *does not use* symbolic icons. That would be the right behaviour (the shell will paint them in the panel) and I think that this should be asked to the maintainer. Cheers, Alessandro ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Faenza-Dark not showing correct icons in shell panel
Moin, I'm using the Faenza-Dark icon theme, the Faenza variant for dark panel backgrounds which contains light panel icons. GS still shows the dark panel icons (from Faenza-Light which is in the same package, -Dark inherits -Light) on it's dark panel, so they're barely visible. In #gnome-shell, one told me that there's something wrong with the svg images since they're being recolored (?) by GS. I want to ask the theme author to fix this, but what exactly should be done for the icons to be shown properly? I.e. what should I ask him to do? Marcel ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
Re: gs crashes while drop the only one window from initial workspace to the second
Please report a bug, mailing list is not for bug reporting. On Tue, Feb 22, 2011 at 4:10 PM, Yu Chen wrote: > how to reproduce it: > > 1, open a terminal window in the initial workspace, > 2, switch to overview > 3, drop the terminal window to the second workspace, > 4, gnome-shell will restart automatically. > > there is not issue with two windows at last in the initial workspace. > > > -- > Yu > ___ > gnome-shell-list mailing list > gnome-shell-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-shell-list > ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
gs crashes while drop the only one window from initial workspace to the second
how to reproduce it: 1, open a terminal window in the initial workspace, 2, switch to overview 3, drop the terminal window to the second workspace, 4, gnome-shell will restart automatically. there is not issue with two windows at last in the initial workspace. -- Yu ___ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list