Re: gs crashes while drop the only one window from initial workspace to the second

2011-02-22 Thread Omer Akram
Please report a bug, mailing list is not for bug reporting.

On Tue, Feb 22, 2011 at 4:10 PM, Yu Chen jco...@gmail.com 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


Faenza-Dark not showing correct icons in shell panel

2011-02-22 Thread Marcel

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


Application categories

2011-02-22 Thread Owen Taylor
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


Re: Window controls for GNOME 3

2011-02-22 Thread Marina Zhurakhinskaya
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 

Mutter 2.91.90 released

2011-02-22 Thread Owen Taylor
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 AltAbove_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


GNOME Shell 2.91.90 released

2011-02-22 Thread Owen Taylor
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 AltAbove_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, William 

Re: Window controls for GNOME 3

2011-02-22 Thread Sriram Ramkrishna
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