Connect to the 'position-set' signal of MetaWindowActor and move
actors when the source windows move.

Intead of using a St.Group and tweening the position of the controls
actor, use a St.GenericLayout and tween a Javascript property. This
allows us to more reliably track the height of the overall workspace
display and propagate it to the controls actor.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

With workspace thumbnails, we don't switch workspaces when dragging windows
between workspaces or adding new workspaces, so we also shouldn't switch
on launch.

 * Add workspace parameters to shell_doc_system_open(),
   shell_app_activate, shell_app_open_new_window()

 * Pass a 'params' object when activating items in the overview with
   two currently defined parameters: workspace and timestamp. (timestamp
   is only implemented where it is easy and doesn't require interface
   changes - using the global current timestamp for the shell is almost
   always right or at least good enough.)

https://bugzilla.gnome.org/show_bug.cgi?id=640996

At the end of a drag operation, we would invoke the code to slide the
controls in (because we were no longer DND'ing and not hovering) and
then immediately afterwards invoke the code to slide it back out when
we got the ENTER event from the end of DND. While the immediately
overridden tween probably won't have any visible effect it's better
to avoid this, so wait to update the zoom state until BEFORE_REDRAW.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

With automatic workspace management, explicit controls to add and
remove workspaces are no longer necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

Automatically add and remove workspaces so that the last workspace is
always empty and no workspaces are empty other than that workspace.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

With workspace thumbnails, we want to make workspace switching
something that happens largely under the users control, so don't
switch to newly added workspaces in the overview.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

Add workspace thumbnails to the workspace controls area. The user can
click on the thumbnail to switch workspaces and can also drag windows
out of the thumbnail to other workspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

Moving the base tracking of restacking to WorkspacesDisplay will allow
us to use it to update stacking in the workspace thumbnails as well as
in the main workspaces.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

Instead of having a separation between popping the controls out on hover
and zooming out for DND, always do both at once. This is necessary because
when we added workspace thumbnails the controls will get bigger, so we need
to make sure we zoom out far enough so that the windows don't overlap the
controls.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

When checking the type of a DND source, instead of checking
'instanceof Workspaces.WindowClone' accept any actor with realWindow
and metaWindow properties. This will be useful to support a separate
type of actor dragged from workspace thumbnails.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

Once we have workspace thumbnails in the overview, workspace indicators
will no longer be needed.

https://bugzilla.gnome.org/show_bug.cgi?id=640996

The new plans for a row of workspace thumbnails on the right side of the
overview means that the mental model we present to the user will be
vertical, so switch the Metacity workspace layout to be vertical and
adjust the keybinding handling, animations, and workspace layout in
the overview to match.

(This commit does not change the workspace switching indicator pending
finalization of what we want to do with that - it still shows workspaces
arranged vertically.)

https://bugzilla.gnome.org/show_bug.cgi?id=640996

During a drag-and-drop, our pointer grab keeps enter/leave events from
being delivered. That means that after the DND ends, whatever actor is
under the pointer won't have received the enter event it should have,
and any state or hover effect dependent on that won't work right.
By remembering the first-leave and last-enter events we can figure out
what widgets we need to call st_widget_sync_hover() on after the drag.

https://bugzilla.gnome.org/show_bug.cgi?id=640974

https://bugzilla.gnome.org/show_bug.cgi?id=641195

https://bugzilla.gnome.org/show_bug.cgi?id=640781

1. Both functions leaked the nodes in priv->children
2. st_container_remove_all wasn't properly updating first_child and last_child
3. remove_all() is almost never right since it won't cause signal handlers
   on the children to be removed. In the rare cases where it might be needed
   the caller can simply use clutter_container_remove().
https://bugzilla.gnome.org/show_bug.cgi?id=640781

https://bugzilla.gnome.org/show_bug.cgi?id=640781

https://bugzilla.gnome.org/show_bug.cgi?id=640781

This will make it easier for users to get back to their chats.

https://bugzilla.gnome.org/show_bug.cgi?id=617234

Hellyna Ng authored Jan 20, 2011 and Dan Winship committed Feb 01, 2011

Users can now use the keyboard and mouse to navigate with buttons
interchangeably, instead of entirely using only mouse.

https://bugzilla.gnome.org/show_bug.cgi?id=630937

The respective version numbers got swapped in commit 703092f2.

Change css_stylesheet to cssStylesheet in various places.

Rename the setter to reflect the fact that it's the stylesheet which is
changing

Add a getter to allow some useful checks

The official GNOME moduleset builds evolution and e-d-s against
GTK+-3, so libedataserverui-1.2 is no longer part of the release.
As GNOME Shell can actually be build with either version, prefer
libedataserverui-3.0 if it is available and allow falling back
to 1.2. if it isn't.

https://bugzilla.gnome.org/show_bug.cgi?id=641085

Sardem FF7 authored Jan 28, 2011 and Dan Winship committed Feb 01, 2011

When the bubble is near the screen border, draw a half arrow at the
corner of the bubble.

https://bugzilla.gnome.org/show_bug.cgi?id=639979

We were not looking at the right field for the message ID: the ID is in
the 4th field for BEGIN_MESSAGE, but 2nd field for CANCEL_MESSAGE.

It just got removed in GTK+ 3, and we actually don't need it since we
look for ClientMessage in na_tray_manager_window_filter() anyway.

http://people.freedesktop.org/~david/calendar-grid-non-US-locale-collapse-bug.png

This was discovered when working on bug 641049:

 https://bugzilla.gnome.org/show_bug.cgi?id=641049



Signed-off-by: David Zeuthen <davidz@redhat.com>

In non-US locales, Monday is generally considered the first day
of the week. Take this into account when building the event
lists displayed under "This week"/"Next week".

https://bugzilla.gnome.org/show_bug.cgi?id=641049



Signed-off-by: David Zeuthen <davidz@redhat.com>

When the current day does not exist in the next/prev month (like 31 Feb),
the next/prev buttons end up skipping the month.

Fix that by going to the last day of the month instead.

https://bugzilla.gnome.org/show_bug.cgi?id=641067

See https://bugzilla.gnome.org/show_bug.cgi?id=632109#c56



Signed-off-by: David Zeuthen <davidz@redhat.com>

https://bugzilla.gnome.org/show_bug.cgi?id=632109



Signed-off-by: David Zeuthen <davidz@redhat.com>