monitor-config: prevent assert that at least one output is connected

Apparently some connector technologies don't distinguish between
on and off, and there might be valid use cases for running without
any connected monitor.
In that case, just avoid any configuration at all.

https://bugzilla.gnome.org/show_bug.cgi?id=709009
Bump version to 3.10.1.1

Update NEWS.
Updated Greek translation
Updated Dutch translation
window: don't ignore resize button release event for move/resize actions

https://bugzilla.gnome.org/show_bug.cgi?id=710251
Bump version to 3.10.2

Update NEWS.
xrandr: use "hotplug_mode_update" property

Use the "hotplug_mode_update" connector property indicating that the
screen settings should be updated: get a new preferred mode on hotplug
events to handle dynamic guest resizing (where you resize the host
window and the guest resizes with it).

https://bugzilla.gnome.org/show_bug.cgi?id=711216
display: Don't focus the no-focus-window when sending WM_TAKE_FOCUS to a globally active window

Clients like on-screen keyboards try not to take focus when the user clicks
on their window by setting the Input hint to false. However, due to GTK+ and
GDK bugs, the public API for setting the Input hint to false don't remove
WM_TAKE_FOCUS from WM_PROTOCOLS, unintentionally putting them into Globally
Active mode.

These clients also expect that since they don't want to take focus, they want
the focus to remain on the existing window. In this case, for clients like
on-screen keyboards, it's so they can send synthesized keyboard events to the
focused window.

https://bugzilla.gnome.org/show_bug.cgi?id=710296
Update Chinese simplified translation
MetaWindowGroup: fix paint volume

In the past, MetaWindowGroup was allocated the size of the screen and
painted the size of the screen because it contained the screen background,
but now we also have the "top window group" which contains only popup
windows, so the allocation doesn't properly reflect the paint bounds
of the window group. Compute the paint bounds accurately from the
children.

https://bugzilla.gnome.org/show_bug.cgi?id=719669
display: Fix checks for KeyPress/ButtonPress

https://bugzilla.gnome.org/show_bug.cgi?id=720545
Fix problems with focus tracking

When a client spontaneously focuses their window, perhaps in response
to WM_TAKE_FOCUS we'll get a FocusOut/FocusIn pair with same serial.
Updating display->focus_serial in response to FocusOut then was causing
us to ignore FocusIn and think that the focus was not on any window.

We need to distinguish this spontaneous case from the case where we
set the focus ourselves - when we set the focus ourselves, we're careful
to combine the SetFocus with a property change so that we know definitively
what focus events we have already accounted for.

https://bugzilla.gnome.org/show_bug.cgi?id=720558
Be willing to unfocus the grab window when we are unmanaging it

When we are unmanaging the grab window, we /need/ to unfocus it,
so we shouldn't bail out early from meta_window_focus().

https://bugzilla.gnome.org/show_bug.cgi?id=711618
display: Don't leave focus on a window we are unmanaging when sending WM_TAKE_FOCUS

When we move focus elsewhere when unmanaging a window, we *need* to move
the focus, so if the target is globally active, move the focus to the
no-focus-window in anticipation that the focus will normally get moved
to the right window when the target window responds to WM_TAKE_FOCUS.

If the window doesn't respond to WM_TAKE_FOCUS, then focus will be left
on the no-focus-window, but there's no way to distinguish whether the
app will respond or not.

https://bugzilla.gnome.org/show_bug.cgi?id=711618
Remove meta_window_new_with_attrs

The compositor code used to handle X windows that didn't have a
corresponding MetaWindow (see commit d538690b), which is why the
attribute query is separated.

As that doesn't happen any more, we can clean up. No functional changes.

Suggested by Owen Taylor.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
Discourage server grabs

Server grabs are not as evil as you might expect, but there is agreement
in that their usage should be limited.

Server grabs can cause things to go rather wrong when mutter emits
a signal while it has grabbed the server. If the receiver of that signal
waits for a synchronous action performed by another client, then you
have a deadlock. This happens with Mali binary GLESv2 drivers :(

https://bugzilla.gnome.org/show_bug.cgi?id=721345
frame: remove unnecessary server grab

meta_window_ensure_frame() creates its own grab and has a comment
claiming that it must be called under a grab too.

But the reasoning given in the comment does not seem relevant here.
We only frame non-override-redirect windows, so we are creating
the frame in response to MapRequest. There is no way that the child
could receive a MapNotify at this point, since that only happens
much later, once we go through the CALC_SHOWING queue and call
XMapWindow() from meta_window_show().

Remove the unnecessary grab.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
screen: use stack tracker for initial window query

In meta_screen_manage_all_windows() we can use our own stack
tracker to get the list of windows - no need to query X again.

A copy is needed because the stack gets modified as part of the loop.
Specifically, meta_stack_tracker_get_stack() at this time returns the
predicted stack, and meta_window_new() performs a few operations
(e.g. framing) which cause immediate changes to the predicted stack.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
meta_window_new: clean up error handling

The return code of XGetWindowAttributes() indicates whether an error
was encountered or not. There is no need to specifically check the error
trap.

The trap around XAddToSaveSet() was superfluous. We have a global error
trap to ignore any errors here, and there is no need to XSync() as GDK
will later ignore the error asynchronously if one is raised.

Also move common error exit path to an error label.

https://bugzilla.gnome.org/show_bug.cgi?id=721345
Reduce server grabs during window creation

Remove some obvious server grabs from the window creation codepath,
also ones that are taken at startup.

During startup, there is no need to grab: we install the event handlers
before querying for the already-existing windows, so there is no danger
that we will 'lose' some window. We might try to create a window twice
(if it comes back in the original query and then we get an event for it)
but the code is already protected against such conditions.

When windows are created later, we also do not need grabs, we just need
appropriate error checking as the window may be destroyed at any time
(or it may have already been destroyed).

The stack tracker is unaffected here - as it listens to CreateNotify and
DestroyNotify events and responds directly, the internal stack
representation will always be consistent even if the window goes away while
we are processing MapRequest or similar.

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