There is very little point in sending an X11 client message to
gnome-panel in case gnome-shell isn't handling the binding. We
can just as well do nothing, so do exactly that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1886>
Using "framebuffer_discard" in the list refers to an invalid extension.
The extension which introduces glDiscardFramebufferEXT is
"GL_EXT_discard_framebuffer".
With this fix, cogl_gl_framebuffer_fbo_discard_buffers can actually call
glDiscardFramebufferEXT.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1974>
The docu for `Popen.wait()` says:
> This will deadlock when using stdout=PIPE and/or stderr=PIPE and
> the child process generates enough output to a pipe such that it
> blocks waiting for the OS pipe buffer to accept more data.
Fixes 3caa5fea3c
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1971>
If for some reason uncrustify gets angry at our file and indent on/off
marks, it will result in an error code other than 0. Since in those
cases there is no output to diff with, we misinterpret those situations
as "the whole file should be deleted", which is far from it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1970>
Borrowed from Tracker, this script has different mode usages:
* --sha allows specifying a commit SHA, HEAD^ by default.
* --dry-run shows suggested changes in stdout, by default
the local tree is changed.
* --rewrite amends the last commit, in addition to performing
the changes.
This allows from simple style checks in the development tree,
automatically rewriting with the suggested changes (e.g. with
`git rebase --exec ./check-style -r`) and CI integration.
The script has per-function granularity, and works by re-styling
individually every commit, and inside every commit every chunk.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1924>
We fetch a frame clock that we schedule update on when queuing
_NET_WM_FRAME_DRAWN events. In some situations this frame clock is the
one from the stage, and if there are multiple hotplugs in a row, we
failed to update it as there were no stage views changes on the window
actor itself. As an actor updates the stage views list on layout, When a
queue_frame_drawn() call was done (typically from an X11 event) after a
second hotplug, it'd attempt to schedule an update on the frame clock
from the previous hotplug, as it didn't get notified about any
stage-views changes since for itself there was none.
Fix this by not caching the frame clock at all and just fetch it every
time.
In the majority of cases, this fetching means iterating over a very
short list (most often a single entry, rarely more), so it's very
unlikely to be of any relevance. The only situations where it might be a
heavier operation is the short time between a hotplug and a layout, as
it will attempt to traverse up to the stage to find a clock, but that's
likely only a few levels, so even that is unlikely to be an issue.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4486
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
Make sure that when we've recreated views that we'll actually paint a
new frame for it. This was very rarely a problem, as views tend to
result in getting damage etc being queued as side effects of various
things, like layout, but e.g. when running certain tests, this might not
happen. There is no situation where we want to create a new view that
should remain unpainted, so just make sure we initialize it to become up
to date.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1947>
This is more in line with the protocol, and allows us to remove some
awkward code that tries to "combine" different metadata from different
monitors into one, which sometimes meant picking an arbitrary "main"
monitor, or "and" metadata together to find a common ground.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1712>
Makes workspace transitions in gnome-shell look more seamless, since
both outgoing and incoming workspace have focused windows.
This is only done for click focus mode, since it's not known which
window would be focused for the other modes.
Track the state and recompute it when it changes, to avoid redrawing
the windows needlessly.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
Each workspace has a window that will be focused when switching to that
workspace. Add a function to retrieve that window.
This is only relevant for click-to-focus focus mode, since with the two
other modes no window will be focused upon switching, and will only gain
focus when hovered.
This will be used in the next commit to make this window appear focused.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/850>
