Only a tiny number of tablet pads that have more than one mode
group, everyone else has one mode toggle button and one group.
Let's not display "Group 0" for everyone if (almost) no-one has a Group
1 anyway.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4248>
HDR being enabled was controlled by toggling a property on
org.gnome.Mutter.DebugControl, which affected how the color space and
HDR metadata of the output was configured. Replace this with a higher
level MetaMonitor / MetaOutput level "color mode" enum, that is also
reflected in the monitor configuration API.
This enum is then used to derive the color space and HDR metadata at the
lower level where it matters. The ForceHDR debug control property is
still left there, as it only affects the color space and transfer
function of the view related to a monitor.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4192>
Commit 48d070dae changed the logic to compare the modifiers mask as a
whole.
Unfortunately, that does not work with all combinations of modifiers, as
some may not be reported when the ISO_Next_Group key is notified.
Revert to the original logic which is to compare against each modifier
mask individually.
Fixes: commit 48d070dae - keybindings: Check for ISO_Next_Group keysym
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4237>
In process_iso_next_group(), we would use try to match mask and keycode
of ISO_Next_Group to tell whether the key combo has been activated.
That works on X11, but not on Wayland with the native backend, because
the keycode does not match.
But we do not need to go all through that burden to match the key combo
we could just use the keysym instead, which would work even when there
is no physical key for ISO_Next_Group.
All we need to do is check whether the symbol is ISO_Next_Group and the
modifier mask matches, which simplifies the code as well.
(Note that we still need to keep the resolved iso_next_group_combo
key combo around because the X11 backend grabs that key combo.)
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/3883
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4232>
The gravity argument is no longer effective since the previous
commit. Drop the argument, and rename it to "meta_window_resize_frame",
all callers have been updated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3972>
We really only need the logind API which can be provided either by
libsystemd or libelogind.
This also pulls out finding a logind provider from the native backend
only code because we make use of it in the generic backend code as well.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4223>
Some are replaced with g_warning(), some are not replaced yet, as they
will be handled differently.
One warning was turned into a META_DEBUG_DISPLAY, due to it being easily
hit in CI, while being extremely unlikely otherwise.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4005>
This makes it possible to use udev even for backends which are not
native. Specifically we want to start controling backlights in mutter
which has to happen for both native and X11.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4130>
As far as I can see this doesn't happen in practice, but theoretically
the uninitialized values can be used if:
1. `did_placement` is TRUE
2. `flags` contains both `META_MOVE_RESIZE_RESIZE_ACTION` and
also `META_MOVE_RESIZE_MOVE_ACTION`
3. `!meta_window_is_tied_to_drag (window)` is FALSE
In that case, the `frame_rect` variable (with uninitialized values) is
passed to `unconstrained_rect`, then passed to `constrained_rect`,
then finally the (uninitialized) X and Y values are read in the
`if (did_placement)` branch.
This is probably a regression from 3047b2ce261. I don't know if this is
the appropriate fix.
Coverity CID: #1511378
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4175>
This is needed to allow tests to manipulate the behavior of the test
shell plugin during startup. Since the plugin is created and started
when the MetaDisplay is created, it needs to be handled via MetaContext,
by setting the options after creating the context, but before starting.
For simplicity reasons, make the options an opaque GVariant, passed via
a an `"options"` property when the plugin object is created, if the
passed options is non-NULL. Only passing the options when non-NULL
allows for backward compatibility.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4152>
This disables the visibility change effects for the dragged window,
which makes it feel a bit smoother.
TODO: Double-check whether this is indeed desirable. Note: ChromeOS imp
does this and Chromium-X11 used to do this at client side.
Status:
- [x] Basic window drag triggering
- [x] Exclude the dragged window from event targets
- [x] Event forwarding (window drag vs wayland grabs)
- [x] Offset calc relative to toplevel geometry
- [x] Attach already mapped windows
- [x] Properly support not-yet-mapped windows
- [x] Disable visibility change animations
- [ ] Dnd events stream adaptations
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
- This adds a new ClutterActor parameter to meta_compositor_drag_window
and meta_window_drag_begin such that it's possible to inject an
external grab actor, which is then used to implement a "non-grabbing"
mode that allow a MetaWindowDrag to be used in conjunction, for
example, with a Wayland drag-and-drop session;
- This new API is going to be used to implement the toplevel drag
protocol in a subsequent commit.
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
- Skip placement constraints when it is set.
- Required to properly support about-to-be-mapped windows, which get
"detached" when dragged out of its original owning window.
Signed-off-by: Nick Diego Yamane <nickdiego@igalia.com>
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4107>
The MetaWindowConfig can indicate whether the configuration reflects on
the initial configuration, before the window is first mapped.
Add a smaller helper (private) window function to create the appropriate
"type" of MetaWindowConfig depending whether the window was already
showed or not.
This is preparation work for the following commits where this function
will be used.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
Use the meta_window_is_fullscreen() API instead of accessing the
fullscreen field of the MetaWindow structure directly.
This is both a (small) cleanup and preparation work for the next commit.
No function change (intended).
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
This is intended to be used in place of the window rect and fullscreen
flags.
That will also allow for a pre-configuration signal to be added, passing
the configuration so that a plugin can tweak the configuration before it
gets applied first.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4076>
