Since we are using the surface actor to draw the DND icon, the offset
is already accounted for by MetaSurfaceActorWayland, and passing the
surface position offset would effectively double the actual offset,
causing the icon to be misplaced.
This patch always sets the anchor offset to (0, 0) when the icon is a
Wayland surface, and lets the surface actor deal with the offsetting.
https://bugzilla.gnome.org/show_bug.cgi?id=759222
We now additionally send:
- wl_data_offer.source_actions
- wl_data_source.action
- wl_data_offer.action
- wl_data_source.dnd_drop_performed
- wl_data_source.dnd_finished
The protocol changes allow for compositors to implement different policies
when chosing the action, mutter uses this to reimplement the same behavior
that GTK+ traditionally had:
- Alt/Control/Shift modifiers change the chosen action to
ask/copy/move respectively
- Drags with middle button start out as "ask" by default
As mutter now also grabs the keyboard and unsets the window focus for these
purposes, the window focus is restored after the drag operation has
finished.
The Xdnd bridge code is also modified to cope with actions, so mixed
wayland-x11 scenarios are able to convey that information.
https://bugzilla.gnome.org/show_bug.cgi?id=760805
This will be useful during DnD, where mutter is expected to consume
keyboard events for either allowing changes in the selected DnD action,
or misc a11y features like keyboard-driven DnD.
Currently, the vtable contains 2 functions, key() will be used on every
key event we get from Clutter, modifiers() will notify of changes in the
keyboard modifiers (mouse buttons will never be set in the modifier mask)
https://bugzilla.gnome.org/show_bug.cgi?id=760805
As per the spec:
- wl_pointer.axis_source determines the current source of
scroll events.
- wl_pointer.axis_stop determines when there's no further
scroll events on the given axis.
- wl_pointer.axis_discrete is emitted on "wheel"
scroll sources, measured in ticks.
- wl_pointer.frame is meant to coalesce events that logically belong
together, e.g. axis events in this case.
Co-Authored-By: Peter Hutterer <peter.hutterer@who-t.net>
https://bugzilla.gnome.org/show_bug.cgi?id=760637
Some of the mutter code using these properties expects them to be
null-terminated whereas xcb does not use null-terminated strings:
http://xcb.freedesktop.org/XcbRationale/
This was in some cases resulting in the WM_CLASS property containing
garbage data which broke application matching, caused the hot-corner and
window-switcher to stop working, or was exposed as text in the UI.
https://bugzilla.gnome.org/show_bug.cgi?id=759658
This fixes an issue analogous to bug 760330 for the X11 backend,
except on this backend we wouldn't crash accessing free'd memory.
Instead we're leaking watches since we steal them from the hash table
which means that when they're removed in
_meta_idle_monitor_watch_fire() they're no longer there and thus
they're never free'd.
https://bugzilla.gnome.org/show_bug.cgi?id=760476
Right now the XSync based idle monitoring code, will fetch all active
watches into a list, and then call their watch callbacks one by one
as necessary. If one watch callback invalidates another watch, the
list will contain free'd memory.
This commit makes sure to consult the hash table after ever call
of a watch callback, to ensure mutter never looks at freed memory.
Fixes crash reported on IRC by Laine Stump with his synergy setup.
https://bugzilla.gnome.org/show_bug.cgi?id=760330
The new tiling code, instead of based around "tiling states", is instead
based around constrained edges. This allows us to have windows that have
three constrained edges, but keep one free-floating, e.g. a window tiled
to the left has the left, top, and bottom edges constrained, but the
right edge can be left resizable.
This system also is easily extended to support corner tiling. We also,
using the new "size state" system, also keep normal, tiled, and
maximized sizes independently, allowing the maximize button to bounce
between maximized and tiled states without reverting to normal in
between. Dragging from the top will always restore the normal state,
though.
https://bugzilla.gnome.org/show_bug.cgi?id=751857
We can know the rotation modes supported by the driver, so
export these as our supported modes, and ensure these modes
are honored on the CRTC primary plane upon apply_configuration().
It is worth noting however that not all hardware will be
capable of supporting all rotation modes (in fact, most of
them won't). A driver independent solution should be in
place to back up the rotation modes unsupported by the
drivers, so this is still a partial solution.
The cursor renderer has also been changed to default to
software-based rendering anytime the cursor enters a
rotated CRTC. Another solution would be actually rotating
the DRM cursor planes, but then it requires applying rotation on
these per-CRTC, and actually transforming the pointer position by
the output matrix. This brings marginal gains, so we use the
"sw" rendered cursor, which will be transformed together with
the primary plane.
https://bugzilla.gnome.org/show_bug.cgi?id=745079
In case a window is hidden when we're ordered to make it transient to
a different parent we must re-evaluate its visibility status or we'll
get into an inconsistent state where the parent is visible and the
child isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=759297
This seems like a more generally useful and intuitive behavior. Note
that, in X sessions, this is what already happened in practice since
meta_display_begin_grab_op() calls meta_window_grab_all_keys() which,
on X11, does meta_window_focus().
https://bugzilla.gnome.org/show_bug.cgi?id=756789
This is a really old behavior introduced in commit
585e362526 which is inconsistent since
it only applies to SSD windows.
If we really want this, we should focus the window elsewhere so that
it applies consistently to all windows.
https://bugzilla.gnome.org/show_bug.cgi?id=756789
Some applications, like Chromium, explicitly set their bounding region
to the client area when full-screen. Detect this case, and allow us to
fullscreen when this happens.
Don't update the stack until after setting the window->transient_for
field. Updating before will cause the stack transient-for constraint to
be missing until the next time constraints are applied.
https://bugzilla.gnome.org/show_bug.cgi?id=755606
The test runner sends a "show" command to the test clients and assumes
this was enough work done by the client to enable the compositor to map
the window. Now that we wait to show a Wayland window until the first
buffer is attached (see bug 750552), we need to make sure that we attach
a buffer before assuming that we have the final stacking order.
So, to in order to continue relying on "show" to be enough to actually
show a window, let the test client wait until it has drawn the first
frame.
This makes the tests using Wayland clients test non-flaky.
https://bugzilla.gnome.org/show_bug.cgi?id=754711
When managing a non-OR window we're required by the ICCCM to behave as
if we received a ConfigureRequest which means that we must generate a
synthetic ConfigureNotify even if the window isn't moved or resized
from its current (initial) geometry.
During MetaWindow's x11/wayland split a slight behavior change for x11
windows crept in. Before the code split, MetaWindow->rect was
initialized with the X window's geometry, but now we're not
initializing MetaWindowX11Private->client_rect which causes the checks
for whether it's necessary to move/resize the window in
meta_window_x11_move_resize_internal() to tell us that we do need to
move/resize which means we do an XConfigureWindow() call and don't
send the sythetic ConfigureNotify. But since the X window isn't really
moving, the XConfigureWindow() call doesn't cause the X server to
generate a ConfigureNotify which breaks some clients such as Java's
AWT.
We can fix this by setting MetaWindowX11Privatew->client_rect for both
OR and non-OR windows. We can set buffer_rect for non-OR windows as
well to simplify the code since it will be assigned the correct value
in meta_window_x11_move_resize_internal() .
https://bugzilla.gnome.org/show_bug.cgi?id=759492
During xwayland initialization we run main loop and dispatch wayland
events, so that xwayland can initialize. If some client during this
phase connects and creates surface, mutter crashes because
it is not initialized yet. If we bind wayland socket after xwayland
is initialized and main loop is not running anymore, no client can
connect to mutter during initialization and that is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=751845
GDesktopTouchpadScrollMethod was used instead of GDesktopTouchpadClickMethod
which became visible now that the former has been removed from
gsettings-desktop-schemas.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
When the touchpad is two-finger scrolling capable, always enable it.
When the touchpad only supports edge scrolling (usually older devices, and
usually smaller devices), allow disabling the edge scrolling.
This requires a newer gsettings-desktop-schemas as the scroll-method key
was removed, and the edge-scroll-enabled key added.
https://bugzilla.gnome.org/show_bug.cgi?id=759304
Wine removes the minimize func from its Motif hints on full-screen
windows, because, as the Win32 API literally says, the minimize button
is indeed not visible on full-screen windows.
Given that this code was added to prevent minimizing a panel by
accident, I don't necessarily think that it's relevant anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=758186
Unsetting it in meta_display_handle_event() will make the pointer
emulation checks fail on TOUCH_END event handlers across clutter
actors, the sequence should still be considered as pointer emulating
at that time.
As we don't have a way to hook this post clutter event handling,
instead unset/reset it lazily on the next pointer emulating TOUCH_BEGIN
event, the checks would already fail on other sequences, even if the
pointer emulating touch ended earlier. The only extra thing we need
to take care about is sequence collision, at which point it's safe to
just unset the stored sequence if its new incarnation isn't flagged/
deemed as pointer emulating.
https://bugzilla.gnome.org/show_bug.cgi?id=756754
The max potential number of logical monitors (i.e. MetaMonitorInfos)
is the number of CRTCs, not the number of outputs.
In cases where we have more enabled CRTCs than connected outputs we
would end up appending more MetaMonitorInfos to the GArray than the
size it was initialized with which means the array would get
re-allocated rendering invalid some MetaCRTC->logical_monitor pointers
assigned previously and thus ending in crashes later on.
https://bugzilla.gnome.org/show_bug.cgi?id=751638
Use the xdg_shell XML file installed by wayland-protocols instead of
our own copy. This protocol has yet to go through any unstable naming,
but since we had an outdated (though wire compatible) version, some
minor changes were needed.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
Remove our own copy of the pointer gestures protocol, and us the one
installed by wayland-protocols. This also means the new fixed unstable
naming conventions are used for the new version of the protocol, which
is reflected in the change. No functional changes were made, it is only
a rename.
https://bugzilla.gnome.org/show_bug.cgi?id=758633
