This are called when a clone directly attaches to an actor. While not
reliable to know whether a particular actor is cloned or not, one can at
least this way get notified about whether an actor in particular is
cloned.
This can be useful for e.g. the MetaWindowActor, as it's what's most
likely cloned, e.g. for alt-tab views etc.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3019>
Adds va_marshallers to the ClutterStage signals. This allows for better
stack traces to be retrieved when profiling. Additionally, since the
generic marshaller was using GBoxedCopy/GBoxedFree functions for the
GValue usage, the previous code was acquiring a global reader/writer
lock in GObject via g_boxed_free() usage.
With G_SIGNAL_TYPE_STATIC_SCOPE, the generated marshallers can avoid
the additional copy/free on the instance.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3204>
Same reasoning holds than with touchpad gesture events in the
previous commit, this will be the first event seen from a specific
device and will require early handling, or crashes may follow.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3198>
With commit be3bca01a7 in place, we now possibly skip early calls
to clutter_stage_repick_device() happening early during initialization.
These were also indirectly the ones that eventually ended up in
the first call to clutter_stage_pick_and_update_device() actually
initializing the PointerDeviceEntry.
With this no longer happening, we may end up with no PointerDeviceEntry
implicitly set up after initialization, which may fail if the first
event received from the seat pointer does not in fact trigger the
clutter_stage_pick_and_update_device() call necessary to make things
work from there on.
And this does indeed happen on touchpads, since the first input event
obtained after CLUTTER_DEVICE_ADDED is CLUTTER_TOUCHPAD_* instead
of CLUTTER_MOTION. This finds an unset PointerDeviceEntry and crashes
since the pointer device does still have no "presence" on the stage.
Fix this by making CLUTTER_TOUCHPAD_* events also trigger a
device update, so the fist event handled does always trigger the
necessary device update.
Fixes: be3bca01a7 ("clutter: Check that pointer has coordinates prior to repick")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2978
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3198>
This data is commonplace enough that it makes sense to keep it
as generic event data. Make these fields take a hard refcount, like
the private data used to do, and drop these fields from the
ClutterEventPrivate struct.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3190>
In future commits, we will want to create DMA-BUFs with pixel
formats other than COGL_PIXEL_FORMAT_BGRX_8888. In preparation
for that, let's start passing a new pixel format parameter to
this function, and the corresponding winsys vfunc.
All callers of this function pass COGL_PIXEL_FORMAT_BGRX_8888
for now. Next commits will change that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3175>
The device/sequence may not currently have a set of coordinates to return.
We correctly leave the out values uninitialized, but don't tell the upper
layers in any way.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3183>
We have a mechanism to trigger repick after animations on
clutter_actor_set_final_state(), but this will not happen if
animations are disabled.
In this case, shell transitions and other typically animatable
changes on the transform of actors will not naturally trigger
a pointer repick when those get instantly changed to the final
state, possibly preserving the cached state and missing the
just popped in actor altogether.
Trigger an instant repick on animation-less transform changes,
so that these situations are also handled correctly, and the
pointer drops the cached state and is able to find the new
actor.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2918
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3168>
The clutter_seat_handle_event_post() function wants to handle
CLUTTER_DEVICE_ADDED/REMOVED to perform signal emission, but
checks (and asserts) that every event going through it has a
source device.
This is no longer quite true for IM events (they are attached
to the ClutterSeat's keyboard, not a HW device), so the assert
can now fire off (of course undesiredly).
But anyways, for events built through
clutter_event_device_notification_new() (the ones this function
is interested in, after all), it is already a precondition check
that the device is proper at the time of creating the event, so
asserting for it here is redundant.
We can drop this overly generic assert, this is already ensured
for the events that matter, anyways.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3167>
With the ClutterEvent subtype structs sealed, this remains the only useful
struct type that is now usable on the Javascript side. Make all
ClutterActorClass event vmethods use ClutterEvent, and update all users
to this change.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3163>
All ClutterEvent users have been changed to use getter methods
instead of direct field access. We may now make the ClutterEvent
union/structs entirely opaque by moving the definitions out of
public headers.
All future usage of ClutterEvent data should be done through
getter methods.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Move the string construction bits in the event logging happening in
MetaSeatImpl to a clutter_event_describe() call, so that it has more
freedom in fiddling with ClutterEvent internals, and may be potentially
reused in other places.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Add methods, and change the API of some rarely used methods, in order
to make all event info currently held/necessary accessible through
ClutterEvent getters, instead of direct field access.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
The full decomposed modifier state is pretty much unused, relying
in keymap signals/properties to track latched modifiers state instead.
The events can be simplified without having this information, and if
it were ever needed in the future, it would be nicer that it had a
dedicated struct and didn't increase the number of arguments in
ClutterEvent constructors.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
We need to change at least event flags in the event we reinject after
it was let through by the IM, in order to avoid doubly handling.
Create a full event copy from the original event parameters.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Avoid peeking in the stage for loosely related actors, since the same
event could be handled by different actors across the picking stack.
This getter is also unused, so there's wiggle room here for changes.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
These constructors take all the necessary arguments to build the
event from the get go, so the callers are not left up with the task
of setting up the event struct data.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
Despite the attempt to make this a generic interface, this was
pretty much used only by the X11 backend, and now it ported away
from it.
This now stands unused and may be removed, in favor of backends
each creating and injecting events as they please.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>
It is a bit backwards that events contain information about
the stage they are being handled by. It makes more sense to
specify in the ClutterEvent handling entrypoint the stage
that will handle the event.
As a first step, add this ClutterStage argument, even though
the information is still carried through the event in order to
keep satisfying calls to the getter function.
This entrypoint has been also renamed to clutter_stage_handle_event(),
so that its ownership/namespace is clearer.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3153>