This might happen when the workspace is not switched and
focus_default_window is called or when 'workspace on primary display
only' is enabled, a secondary display exists and the workspace is
switched.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2747>
There's 2 users of this, meta_display_sync_wayland_input_focus() which
does already perform these checks on its own, and MetaCursorTracker's
update_displayed_cursor() to determine whether it should go with the
Wayland client's cursor.
This second check should also consider the existing ClutterGrabs, so
make meta_display_windows_are_interactable() handle them for both
callers.
Fixes the cursor shown over windows while e.g. there are menus opened.
Close: https://gitlab.gnome.org/GNOME/mutter/-/issues/2553
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2754>
This code path is important for "empty" commits to ensure we schedule
frame callbacks even if previous commits didn't cause stage redraws.
There is, however, no reason to schedule updates on all stage views
instead of only those the actor is on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
Avoid some allocations, save some CPU cycles and make the code easier
to read.
Behaviourwise the only expected change is that now, if there are mapped
clones, we unconditionally choose the view with the highest refresh
rate the actor (or one of its clones) is on and don't check the
obscurred region any more.
Thus in some cases a client may receive a higher rate of frame callbacks
when obscured on a faster view while a clone is present on a slower
one. The assumption is that cases like this are relatively rare and
that the reduction of code complexity, the reduction of allocations in
`meta_surface_actor_is_obscured_on_stage_view()` whenever the actor is
not fully obscured and has clones on other views, as well as generally
fewer lookups and less code in most common cases, compensate for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2671>
We only support feedback-actors, such as DnD-icons, in the compositing
path at the moment.
The approach is similar to how we handle certain shell elements.
Implementations need to ensure no references to the object keep
around longer that necessary.
Arguably this should be replaced by a more robust and implicit actor
hierachy detection in the direct scanout code at some point.
Closes https://gitlab.gnome.org/GNOME/mutter/-/issues/2470
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2677>
The fields of 'priv->video_format.max_framerate' are all of type
uint32_t. Multiplying by G_USEC_PER_SEC can overflow, and equally,
dividing a large numerical type by uint32_t can err too.
Since the variable holding the result is int64_t, cast all uint32_t
fields to int64_t before doing any maths on it.
Spotted while trying to investigating an issue with framerates on
HDMI screencasts.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2762>
Unused since https://gitlab.gnome.org/GNOME/mutter/merge_requests/932
AFAICT.
As a bonus, gets rid of these compiler warnings:
../cogl/cogl/cogl-pipeline-layer-state.c: In function ‘cogl_pipeline_get_layer_min_filter’:
../cogl/cogl/cogl-pipeline-layer-state.c:1279:10: warning: ‘min_filter’ may be used uninitialized [-Wmaybe-uninitialized]
1279 | return min_filter;
| ^~~~~~~~~~
../cogl/cogl/cogl-pipeline-layer-state.c:1274:22: note: ‘min_filter’ was declared here
1274 | CoglPipelineFilter min_filter;
| ^~~~~~~~~~
../cogl/cogl/cogl-pipeline-layer-state.c: In function ‘cogl_pipeline_get_layer_mag_filter’:
../cogl/cogl/cogl-pipeline-layer-state.c:1291:10: warning: ‘mag_filter’ may be used uninitialized [-Wmaybe-uninitialized]
1291 | return mag_filter;
| ^~~~~~~~~~
../cogl/cogl/cogl-pipeline-layer-state.c:1287:22: note: ‘mag_filter’ was declared here
1287 | CoglPipelineFilter mag_filter;
| ^~~~~~~~~~
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2757>
Add a helper function that ensures any queued virtual input events have
been flushed from the input thread. This works by posting a task to the
input thread, which will itself queue another callback back to the main
thread. Once the main thread callback is invoked, the flush call is
unblocked and the function returns. Upon this, any previously emitted
virtual input event should have already passed through the input thread
back into the main thread, however not necessarily fully processed.
For making sure it has been processed, one also have to make sure the
stage has been updated, e.g. via `meta_wait_for_paint()`.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2727>
After the commit "wayland/subsurface: Implement
meta_wayland_surface_get_window()" subsurfaces are supported. Adjust
some comments and fix a warning that could occur when closing a window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The intention here was to check if the subsurface belongs to a window.
Thus it didn't behave as expected for subsurfaces belonging to non-toplevel
windows.
After the previous commit we can use `get_window()` to check for what we
actually want here.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
Subsurfaces are special regarding windows as they don't have a window,
but usually have an ancestor which does. All current users of
`get_window()` are either used for known surface roles, such as xdg-*
ones, or, as is the case for pointer constrains, would actually want to
get the ancestors window.
Thus implement `get_window()` to allow pointer constrains to work.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2223
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2717>
The meta_prop_get_motif_hints() function was only used in the
old MetaUI frames code. The remaining code in mutter accesses
directly the MetaPropValue when loading properties for a window,
and does not use this API call.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
Since we use XCB in the Mutter side, but Xlib in the frames client,
we cannot share the same struct definition since both libraries
will expect different type lengths (respectively, 32-bit ints vs.
longs).
Revert the changes that made both executables share the same
struct, since not both of them can get it right (and retrieve
correctly the struct with the contained flags) in reading the
Motif WM hints.
This reverts commit 2fb3c5a4f5.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2741>
Adding the 'default-decoration' CSS class to MetaFrameHeader after
it is set as the headerbar makes it not account for the minimum size
correctly sometimes. This is a bit racy though - if the window opens
very quickly, it works as expected.
Adding the CSS class before the widget is used guarantees it'll
always report the correct size though, so do that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2753>
The Python docs recommends using run() for all use-cases it can handle:
https://docs.python.org/3/library/subprocess.html#using-the-subprocess-module
run() waits for the subprocess started to complete, so it's not
necessary to use wait() and communicate() anymore. This simplifies the
script.
Previously running "check-style.py -r" after each commit in an
interactive rebase failed, b/c the script did not wait for the amend
command to complete. Using run() instead of Popen() solves this issue.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2733>
Before this, new files introduced by the range of commits checked were
not considered for formatting b/c uncrustify was always turned off in
the beginning of the files, and never turned back on.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2733>
Add this CSS class both to the header bar itself, since it is what
actually contains the window controls, and to MetaFrameHeader too,
since it's what's directly attached to the window.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
Previous commit added support for setting the GTK4 theme setting
according to the color scheme setting. That's cool. What it didn't
add, though, was initializing the GTK4 theme setting to the proper
value. That means if the desktop starts at dark style, you'd still
get a light titlebar.
Fix that by updating the GTK4 theme setting on init as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2740>
These are now referenced on the frames client side (in order to
track deletable state from the client window) and the mutter side
(pretty much everything else, like figuring out if a window wants
WM decorations).
It makes sense to make this a separate header, so that we don't
need to doubly define these flags/structs.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
We use this for tracking the deletable state of the client window,
but forgot to check that the MWM_HINT_FUNCTIONS hint is set in
hints.flags before checking hints.functions.
This resulted in windows that do not specify this flag (and thus
should go with the defaults) in being mistakenly removed the close
button, as the functions flags would be typically 0 in that case.
Fixes issues with Chromium and Electron applications missing the
close button, since Chromium does this on X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
Recalculating window features is a busy thing on the Mutter side, the
different properties being (re)set will overwrite the current state
and cause some side work. Between that is the rewriting of the
_MUTTER_NEEDS_FRAME property on the window being recalculated, which
throws the frames client off, by thinking the window does actually
require a new frame.
It is not sufficient to trust that PropertyNewValue means the property
or the value are new, also double check that the window did not have
in fact a frame, and avoid the busy work if it did.
Besides the busywork that can be easily avoided, this also fixes the
window close button state being stuck if the window changed its
deletable state, since the frame being respawn managed to miss the
property change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2735>
