This reverts commit a7fbf7e1.

By mistake committed to 3-2 branch instead of master

Update NEWS

meta_window_actor_set_redirected makes X calls on the client window
so it need to set error traps.

We never destroy the later list that's added by meta_later_add.

==4289== 16 bytes in 1 blocks are definitely lost in loss record 1,632 of 7,258
==4289==    at 0x4C2640D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4289==    by 0x5178D9F: standard_malloc (gmem.c:88)
==4289==    by 0x5178E37: g_malloc (gmem.c:164)
==4289==    by 0x51924B5: g_slice_alloc (gslice.c:842)
==4289==    by 0x5194521: g_slist_insert_sorted_real (gslist.c:900)
==4289==    by 0x519465A: g_slist_insert_sorted (gslist.c:957)
==4289==    by 0x4EA609A: meta_later_add (util.c:876)
==4289==    by 0x4E9C330: meta_screen_queue_workarea_recalc (screen.c:2640)
==4289==    by 0x4E9A360: update_num_workspaces (screen.c:1646)
==4289==    by 0x4E99026: meta_screen_new (screen.c:924)
==4289==    by 0x4E7AB51: meta_display_open (display.c:803)
==4289==    by 0x4E9168E: meta_run (main.c:552)

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

Update NEWS

We should still correct the coordinates for withdrawn windows.

When we reparent a window to the root when we're exiting, we need to offset
the position by the invisible borders, otherwise windows will creep up and
to the left.

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

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

meta_window_get_current_tile_area() computes the area where the tiled window
should be based on the current pointer position but that's only meaningful
when the user is actually dragging the window.

When running the tiling constrain the pointer might be on other monitor and at
that point the window jumps to this other monitor.

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

When using more than one monitor, tiled maximization can be triggered with the
pointer in one monitor while most of the window area remains in another. This
means that the maximization constraint would maximize the window into the wrong
monitor as it uses the work area size/position as target.

Fix this by using the current tile area as target size/position.

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

In particular this would a cause a "flash" when showing the tile preview for
maximization on a non-primary monitor.

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

Since the frame window size that meta_window_move_resize() uses depends
on whether the window has horizontal/vertical resize functionality, we
need to update this flag before we resize the window.

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

If a window had a type hint intended for override-redirect windows
like NOTIFICATION, we ended up with a window that was decorated but
with a frame type of FRAME_TYPE_LAST, causing assertion failures.
Fix this by making recalc_window_features() just call
meta_window_get_frame_type().

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

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

Sandro Mani authored Oct 08, 2011 and Jasper St. Pierre committed Oct 08, 2011

The theme state used to use GtkStateType, but was ported over to GtkStateFlags,
leaving behind a broken assertion that fails when using certain Metacity
themes, for example Nodoka.

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

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

Since window->frame_bounds is used as a cache we need to invalidate it when
destroying the frame.

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

Invisible borders are all about resizing -- in the case that a window
cannot be resized, it makes no sense to add them.

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

We have to free the list returned by clutter_actor_get_effects() .

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

Update NEWS

_NET_FRAME_EXTENTS should contain the difference between where a window asked
to be placed, and where it is. Ideally, this should be the same as the visible
extents.

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

A window can specify geometry that it is placed at. We need to exclude invisible
borders when calculating where to place the window, otherwise the window will have
a strange offset.

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