When we update state, we might not have set the current config yet (for
example if the Xrandr assignment didn't change), so pass the monitors
config we should derive from instead of fetching it from the monitor
config manager.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
We currently only save synchronously when running the test suite, but
should still not leak the generated config buffer. We also created the
cancellable but never used it if we saved synchronously, so lets stop
doing that too.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
The cancellable should only be cleared if we weren't cancelled, as if
we were cancelled, the path cancelling have already cleared the
cancellable.
https://bugzilla.gnome.org/show_bug.cgi?id=787477
We cleaned up an unused monitor config list, but what we should do is
clear up the logical monitor config list. This commit does that, as
well as removes the unused monitor config list.
We have not enough control over the sources of the refresh rate
float variable to make == comparisons reliable, add some room
when comparing these.
https://bugzilla.gnome.org/show_bug.cgi?id=787668
We would free the shortcut inhibit data only when the client destroys
its request, which is not the case when the clients itself is
destroyed, leading to a leak of the shortcut inhibit data.
Free the data on resource destruction instead, and simply destroy the
resource on destroy request.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
On Wayland, the grab()/ungrab() in gtk+/gdk are wired to the shortcut
inhibitor mechanism, which in turn shows the dialog, which can take
focus away from the client window when the dialog is shown.
If the client issues an ungrab() when the keyboard focus is lost, we
would hide the dialog, causing the keyboard focus to be returned to the
client surface, which in turn would issue a new grab(), so forth and so
on, causing a continuous show/hide of the shortcut inhibitor dialog.
To avoid this issue, keep the dialog around even if the shortcut inhibit
is canceled by the client, so that the user is forced to make a choice
that we can reuse on the next request without showing the dialog again.
Instead of hiding the dialog when the shortcut inhibitor is destroyed by
the client, we simply mark the request as canceled and do not apply the
user's choice.
https://bugzilla.gnome.org/show_bug.cgi?id=787568
The brightness is about the vignette. Add a 'vignette_' prefix in order
to give more context. Keep the property name as it is, doing so we don't
break any plugin (e.g., gnome-shell).
https://bugzilla.gnome.org/show_bug.cgi?id=786618
Add the word 'vignette' in order to give some context on what the
snippets do. This will be useful later when we land other snippets
for the gradient effect.
https://bugzilla.gnome.org/show_bug.cgi?id=786618
The reverted commit seems to cause
https://bugzilla.gnome.org/show_bug.cgi?id=787240 for some reason. Lets
be safe and revert it for now, as the code freeze is just around the
corner.
This partly (it doesn't reintroduce a whitespace issue) reverts commit
dbc63430d8.
When cleaning up the display name string management, the display name
string retrieved from libwayland-server was also passed to free() on
clean up. This is invalid as the display name string ownership is not
transferred to us. Fix this by strdup:ing the string before saving it.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
Give clients (such as Xwayland) a chance to bind the wl_output global
before we continue, otherwise there is an significant risk that mutter
won't see the bind request until after the next hot plug which might
have destroyed the global object.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
This avoids updating state (such as position, size etc) when going
headless. Eventually, when non-headless, things will be updated again,
and not until then will we be able to update to a valid state.
https://bugzilla.gnome.org/show_bug.cgi?id=730551
