In the wayland code we are in synchronization with the events that
the ClutterStage is managing at the moment. Asking the ClutterSeat for
the pointer position gets ahead of the current events, and may result
in imprecise coordinates sent in wl_pointer.enter.
To be in consistence with the motion events that might be already
queued, we should ask the stage for the last known coordinates.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1654>
As planned and prepared with the last commits, let ClutterStage take
care of tracking input devices and their respective actors. This means
we now can remove the old infrastructure for this from
ClutterInputDevice.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1633>
Instead of using native backend platform data specifically, store
this info in ClutterMotionEvent. This includes time in usec since
it's just used for motion events, in the future it could make sense
to make these general to all events again, but it could make sense
to make ClutterEvent structs private before.
In order to express that a motion event has relative motion info,
the CLUTTER_EVENT_FLAG_RELATIVE_MOTION event flag has been added
for it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
We have this as platform-dependent data in the native backend, and
a bunch of fallback code done in place in the evcode users. Stop
making this platform-dependent data, and move it to the relevant
ClutterEvents.
The fallback code for the X11 backend case is about the same, but
now it is done directly by the X11 backend.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1623>
Make the clutter_input_device_get_actor() API public and remove
clutter_input_device_get_pointer_actor() in favour of the new function.
This allows also getting the "pointer" actor for a given touch sequence,
not only for real pointer input devices like mice.
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1275
Remove the rather useless callback function that's currently used for
handling the "visibility-changed" signal and instead connect to the
signal using `g_signal_connect_swapped()`.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1077
Using `-Dnative_backend=false` caused build failure due to a missing
(implicit) definition of `META_IS_BACKEND_X11`. But if we define it
properly then that just leaves some of the function's locals uninitialized
and it will never work anyway. Just return unconditionally if there's no
native backend to initialize the variables.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1025
Just go ATM through backend checks, and looking up directly the
native event data, pretty much like the rest of the places do that...
Eventually would be nice to have this information in ClutterEvent,
but let's not have it clutter the MetaBackend class.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/852
When a Wayland window is mapped or unmapped, the Wayland compositor is
expected to send the coorespoindign `wl_pointer` enter/leave events to
the affected clients.
To do so, mutter calls `meta_wayland_compositor_repick()` which
eventually calls `meta_wayland_pointer_repick()` and
`repick_for_event()`.
If pointer input device has not been updated yet, the old clutter actor
is picked and no enter/leave event is emitted.
Make sure we update the pointer input device prior to do the repick to
get the actual `ClutterActor` under the pointer.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/1016https://gitlab.gnome.org/GNOME/mutter/merge_requests/1026
Similar to wl_list_foreach(), add
META_WAYLAND_SURFACE_FOREACH_SUBSURFACE() that iterates over all the
subsurfaces of a surface, without the caller needing to care about
implementation details, such as leaf nodes vs non-leaf nodes.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/961
This is inspired by 98892391d7 where the usage of
`g_signal_handler_disconnect()` without resetting the corresponding
handler id later resulted in a bug. Using `g_clear_signal_handler()`
makes sure we avoid similar bugs and is almost always the better
alternative. We use it for new code, let's clean up the old code to
also use it.
A further benefit is that it can get called even if the passed id is
0, allowing us to remove a lot of now unnessecary checks, and the fact
that `g_clear_signal_handler()` checks for the right type size, forcing us
to clean up all places where we used `guint` instead of `gulong`.
No functional changes intended here and all changes should be trivial,
thus bundled in one big commit.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/940
Just like sync_focus_surface() does, we shouldn't set a focus surface while
the pointer is hidden, so the illusion that there is none remains.
Closes: https://gitlab.gnome.org/GNOME/mutter/issues/779
Flatten the subsurface actor tree, making all surface actors children
of the window actor.
Save the subsurface state in a GNode tree in MetaWaylandSurface, where
each surface holds two nodes, one branch, which can be the tree root
or be attached to a parent surfaces branch, and a leaf, which is
used to save the position relative to child branch nodes.
Each time a surface is added or reordered in the tree, unparent all
surface actors from the window actor, traverse all leaves of the
tree and readd the corresponding surface actors back to the window
actor.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/664
The end goal is to have all clutter backend code in src/backends. Input
is the larger chunk of it, which is now part of our specific
MutterClutterBackendNative, this extends to device manager, input devices,
tools and keymap.
This was supposed to be nice and incremental, but there's no sane way
to cut this through. As a result of the refactor, a number of private
Clutter functions are now exported for external backends to be possible.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/672
This is important when using a touchscreen or stylus instead of a mouse
or touchpad. If the cursor only gets hidden and the focus stays the
same, the window will still send hover events to the UI element under
the cursor causing unexpected distractions while interacting with the
touchscreen.
Fix this by emitting a visibility-changed signal from the cursor tracker
which then triggers a focus surface sync and always set the focus
surface to NULL when it's synced while the cursor is hidden.
https://gitlab.gnome.org/GNOME/mutter/merge_requests/448
The order and way include macros were structured was chaotic, with no
real common thread between files. Try to tidy up the mess with some
common scheme, to make things look less messy.
Rename the two cursor role types according to the convention used by the
other roles. This means that MetaWaylandSurfaceRoleCursor was renamed to
MetaWaylandCursorSurface, and MetaWaylandSurfaceRoleTabletCursor was
renamed to MetaWaylandTabletCursorSurface. The corresponding filenames
were renamed accordingly too.
https://gitlab.gnome.org/GNOME/mutter/issues/77
More specifically, avoid crossing events, since clutter does not set
modifier/button state on those. Fixes implicit grabs being broken when
the pointer moves past the surface boundaries.
https://bugzilla.gnome.org/show_bug.cgi?id=785347
Previously, the function only returned `TRUE` if the given surface was
equal to the given pointer's focused surface. This changes the behaviour
to also return `TRUE` if any of the given surface's subsurfaces are
equal to the pointer's focused surface.
https://bugzilla.gnome.org/show_bug.cgi?id=781811.
Use the "destroy" MetaWaylandSurface signal instead of the wl_resource
destroy signal for tracking the lifetime of the surface with pointer
focus.
As unsetting the focus may have side effects due to handlers of the
"focus-surface-changed" signal, connect the signal after the default
handler to make sure other clean up facilities have the chance deal with
the surface destruction before we try to unset the focus.
https://bugzilla.gnome.org/show_bug.cgi?id=783113
Let the backend initialize the cursor tracker, and change all call
sites to get the cursor tracker from the backend instead of from the
screen. It wasn't associated with the screen anyway, so the API was
missleading.
https://bugzilla.gnome.org/show_bug.cgi?id=777732
We shouldn't cancel the pointer grab when there is a compositor grab,
since that'd break things like drag-n-drop via the overview and
alt-tabs.
The original reason for cancelling the pointer grab on compositor grabs
was to avoid a re-entry when a compositor grab was activated while
there was an active pointer constraint grab. The re-entry would happen
when the compositor grab cleared the pointer focus. Clearing the focus
would trigger the pointer constraint to be deactivated, which would end
its grab. Ending the grab would reset the grab to the default one, which
could focus the same surface again, triggering the constraint to
re-enable before it finished disabling.
This is now avoided because the default grab handler is now aware of
compositor grabs, and won't override the cleared pointer focus until
the compositor grab ends.
https://bugzilla.gnome.org/show_bug.cgi?id=772914
Teach the default grab about compositor grabs (i.e.
display->event_route) so that it can avoid setting a pointer focus when
after the compositor grab actively unset the pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=772914
Previously a grab could suddenly end without the grabber knowing
anything about it. Some grabs assume they won't suddenly end without
notice, and can use then new 'cancel' vfunc to be notified.
Currently a grab is cancelled when a new one is started (i.e. in
meta_wayland_pointer_grab_start()), when a non-popup compositor wide
event route is initiated, and when the seat looses the pointer
capability.
https://bugzilla.gnome.org/show_bug.cgi?id=771858
Instead of using meta_wayland_pointer_end_grab() which focuses the new
grab, add a new helper mean to be used to reset the grab state without
changing the pointer focus. When using this function, the call site is
supposed to explicitly manage focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Make the caller of focus setting check whether there is a pointer to
update the focus state of. It makes it more obvious what to expect, as
the call would be a no-op in when no pointer is present.
Grabbing is still allowed without the presence of a pointer because it
is used by popups even on touch-only systems.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Previously the focus was reset implicitly by a memset() on the whole
MetaWaylandPointer struct. When MetaWaylandPointer was turned into a
GObject, this was not possible any more, and the focus was not updated
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=771646
Instead of initializing the default grab when the device class is
enabled, initialize it on object initialization. This way other device
classes can still grab the pointer, as if there was one. This may be
useful for example if a touch grab is active and a mouse is connected.
This also makes it possible for popup grabs, which currently use a
pointer grab for controlling, to be triggered by touch devices, while
still holding an active pointer grab.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Make the device <-> seat association permanent, and move it into
MetaWaylandInputDevice. A device will never be disassociated with a
seat, so there is no point in unsetting it.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Add a new object class, MetaWaylandInputDevice, and make all device
classes (pointer, keyboard, touch) inherit it. In the future common
functionality may be placed there.
https://bugzilla.gnome.org/show_bug.cgi?id=771305
Add a signal that is emitted when the pointer focus surface of the
pointer device changes. This will later be used by the pointer
constraints to maybe enable pointer constraints when a surface receives
pointer focus.
https://bugzilla.gnome.org/show_bug.cgi?id=771050
