This used to be the HW device that triggered the crossing (i.e.
the mouse moving the pointer, etc), or the logical device if the
crossing event happened through other means than input device
events, e.g. relayouts.
The move to ClutterEvent constructors went a bit too far in
the simplifications and broke these expectations for input-generated
crossing events.
Make this event constructor behave like the other events: receive
a source device, and figure out the corresponding logical device from
there. Also pass the source device as it'd be expected, in the
input-induced crossing event generation paths.
Fixes: a8c62251f8a ("clutter: Port stage crossing events to new constructors")
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2981
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3256>
The stage has the knowledge about input that is ongoing over it
(incl. things like styli and touchpoints). Add an iterator API
for these devices/touchpoints, so they can be used for calculations
and heuristics in other places of the code.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3059>
The assertion for !implicit_grab_cancelled in the
`grab_actor == old_grab_actor` case of
clutter_stage_notify_grab_on_pointer_entry() is meant to do a simple
sanity-check to ensure the grab machinery is working as intended: During a
seat grab, all input gets delivered to the tree inside the grab, and all
implicit grabs outside of that tree are cancelled.
When a new seat grab on the same actor as the existing one happens, we run
through the cancellation machinery for implicit grabs anyway, so we might as
well check that the assumption mentioned above holds true: By asserting that
no implicit grabs were cancelled, we know that no implicit grabs exist
outside of the existing seat grab tree.
This assertion is slightly over-eager though due to the way we set
implicit_grab_cancelled: We initialize it to TRUE in the
entry->press_count > 0 case and then only set it to FALSE once we find an
implicit grab that may remain active. If there are no implicit grabs though
(while entry->press_count is still >0), we never set implicit_grab_cancelled
to FALSE, triggering the assertion in question even though no implicit grabs
got cancelled.
There's two possible solutions for this: Either dropping the assertion, or
refactoring it so it observes the situation where the implicit grabs were
already undone. This commit implements the latter.
Closes: https://gitlab.gnome.org/GNOME/mutter/-/issues/2700
Fixes: debbd88f8c8 ("clutter/stage: Cancel parts of implicit grabs when ClutterGrabs happen")
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3216>
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>
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>
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>
This adds some plumbing to get the "default" paint flags for regular
stage painting, where one either wants to paint the overlay, or not.
If inhibited, the 'no-cursors' paint flag is used, otherwise the 'none'
flag. This will be used to allow having a per stage view hw cursor
state.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2777>
An input only grab is a ClutterGrab on the stage that doesn't have an
explicit actor associated with it. This is useful for cases where event
should be captured as if focus was stolen to some mysterious place that
doesn't have anything in the scene graph that represents it.
Internally, it's implemented using a 0x0 sized actor attached directly
to the stage, and a clutter action that consumes the events. An
input-only grab takes a handler, user data and a destroy function for
the user data. These are handed to the ClutterAction, which handles the
actual event handling.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2628>
The drag actors were practically unused, and became wholly
unused API with commit eb6e1f694a. There is no provision for
using this in the future, so drop this internal API.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3058>
This will consist of device-added events, meaning before init finishes,
we can derive some state that depends on the set of input devices
available on startup, such as cursor visibility.
This avoids cursor visibility switching between hidden and visibility
during startup.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3070>
We're using clutter_stage_schedule_update() now from ClutterActor to kick
off the stage updating machinery when a redraw needs to happen.
This introduced a bunch of unnecessary calls to
clutter_stage_schedule_update() and thus
clutter_stage_view_schedule_update() when multiple actors request redraws
during the same stage update cycle, which is a very common case.
Cut off all those unnecessary calls by bailing out in
clutter_stage_schedule_update() when updates are already queued.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
So far our logic for queueing redraws goes like this: Actor notices that it
needs to redraw -> actor tells stage that it needs to redraw via
clutter_stage_queue_actor_redraw() -> stage collects more and more redraws
into a QueueRedrawList before the actual stage update happens -> when
that happens, the stage collects the actual redraw clips from the actors via
clutter_actor_get_redraw_clip().
The logic behind this QueueRedrawList was that by storing a list of
redraw entries on the stage, way we can avoid traversing the whole actor
tree one more time to build the redraw clip before the stage update.
These days we have clutter_actor_finish_layout() though, which is basically
exactly that, a whole actor tree traversal that happens before every stage
update.
Since we have that now, we might as well get rid of the whole dance back and
forth between ClutterStage and ClutterActor, and simply merge the logic to
queue redraws into the finish-layout step.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2679>
When building mutter with -Ddebug=false, a warning appears, that
`ClutterStagePrivate *priv` is unused.
Simply remove this variable and directly use `stage->priv` in
`CLUTTER_NOTE` to get rid of this warning.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3046>
For now, it goes the "easy" way of creating the root node and
immediately painting and destroying it. From now on, the main
root node is created only by ClutterStage itself.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3007>
This aims to reduce the amount of pixels that have to be redrawed on the
screen on a clipped actor redraw in case using the union of two
different clips in a surface will substantially increase the redrawn
area.
This should not result in excessive memory consumption as callers of
`clutter_actor_queue_redraw_with_clip` are expected to ensure that the
redraw clip rectangles are adequately deduplicated.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2965>
For motion-induced crossing events, this will be the device that generated
the motion. For code-induced crossing events (e.g. grabs or actors disappearing)
this will be none.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2828>
A ClutterGrab takes precedence over implicit grabs, so when one happens,
let's check which part of the implicit grab tree is inside the new
ClutterGrab. Cancel and remove the parts which aren't, and if nothing
is in there anymore, cancel the whole implicit grab.
Emitting crossing events correctly here is getting quite tricky:
- When the implicit grab didn't get cancelled by the ClutterGrab, we
simply want to emit all GRAB_NOTIFY crossings to the implicit grab, as
we do with all other crossings.
- When the implicit grab did get cancelled and the new ClutterGrab wants
to emit ENTER crossings, we want those to be emitted to the actual
targets, so cancel the implicit grab before emission.
- In the last case where the implicit grab did get cancelled and the new
ClutterGrab wants to emit LEAVE crossings, those should be emitted to
the implicit grab again, so we cancel the grab only after the emission
of those.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Now that we have two kinds of grabs, the intricacies of event delivery
got slightly more complicated. So this seems like a good point to
introduce a new GRABS debug flag that gives an overview of which grabs
are currently in effect.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
We're almost there, everything is in place to notify ClutterActions
about a sequence getting pulled away under its feet.
The only thing that's missing is the actual notification to actions now,
so let's do that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Another baby step just like the last commit: This commit takes care of
the opposite case: An action handling a sequence event stops further
emission of events to actors.
Since sequences remain around for longer than the context of just a
single event, it makes sense to provide a way to "claim" those sequences
even when outside of event handling context, so introduce API for that.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
As soon as any event of a sequence is handles/stopped during emission,
all actors and actions that would have gotten to see it afterwards have
a big problem: If that event was a TOUCH_END event, the actor/action is
forever going to think that this touch is still active.
For ClutterActions, we're going to handle this by introducing a way to
send them a notification when stuff like this happens.
As a baby step towards all that, make event emission exclusive to actors
as soon as any actor stopped an event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
We'll soon introduce a new gesture tracking framework which heavily
depends on ClutterActions seeing all events of a sequence. For this to
work, a larger change to event delivery is needed: Implicit grabbing of
all events for button and touch press->motion->release sequences to
ensure ClutterActions continue receiving events for the whole sequence.
This commit takes care of that: At the start of an event sequence we
collect all the event-handling actors and actions to a GArray that lives
in the PointerDeviceEntry, and then deliver all events belonging to
that sequence to the same actors/actions until the sequence ends.
To avoid events getting pulled from under our feet when mutters event
filter returns CLUTTER_EVENT_STOP, this also introduces private API
(maybe_lost_implicit_grab()) on ClutterStage so that we can't end up
with stale sequences.
Note that this also slightly changes behavior when it comes to event
delivery to actions: Because we now store actions separated from their
actors, any action returning CLUTTER_EVENT_STOP now stops event
propagation immediately. That was different before, where we'd emit
events to all actions of the actor and only then stop propagation.
Note that this isn't handling ClutterGrabs correctly right now,
this will be a little tricky, so we'll take care of that in a future
commit.
To handle actors getting destroyed or unmapped during a grab, listen to
notify::grab on the deepmost actor in the implicit grab tree. This gives
us a notification when any actor inside the tree goes unmapped.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
A fairly small refactor, move the emission of events to actions from
clutter_actor_event() to stage level.
We do this because in the future we'll need to know on stage level
whether events were handled by an actor or by an action.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
_clutter_actor_handle_event() currently allocates a new GPtrArray on the
heap for every single event emission, let's avoid this by keeping an
array around in ClutterStage and reusing that.
This is moving the last few bits of event emission into ClutterStage,
which will be useful when we introduce implicit grabbing in subsequent
commits.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
There's no real reason to keep those events exclusive to the stage, some
actors or actions might want to get notified about proximity events too,
so propagate them like any other event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
Right now and due to loads of refactorings lately, the event emission
paths are a bit cluttered (ha ha ha) around in Clutter. For example the
event target actor gets set in clutter-main.c, but event emission is
actually managed by ClutterStage these days.
Since we'll introduce implicit grabbing of touch/button-press sequences
soon, let's shuffle things around a bit to make that easier:
Move event emission to the stage, it now gets a ClutterEvent without any
extra context like the target actor from clutter-main. The stage then
looks up the target actor itself and emits the event to the appropriate
actors in the scenegraph. A special path is introduced for emitting
crossing events, because here the event-receiving actors don't follow
the "capture+bubble from pointer actor to grab actor" rule.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2342>
That means before-update, prepare-paint, before-paint, paint-view, after-paint,
after-update. While yet to be used, it will be used as a transient frame
book keeping object, to maintain object and state that is only valid
during a frame dispatch.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2795>
When we remove a child, we stop its transitions (animations), but we
didn't stop animations on grand children. What we did, however, was to
clear the stage views of the grand children, and this caused a bunch of
orphaned transitions (ClutterTimeline) and accompanied warnings.
Make it so that if we stop transitions, and clear stage views, also stop
transitions for the grand children. Detached children don't have a way
to continue animating anyway, since they have no stage view (thus frame
clock) to be driven by.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2716>
We've been sending all events to clients immediately for quite some time
now, so this is only really impacting the Clutter scene graph, not
clients anymore.
That makes this behavior a somewhat unnecessary optimization (it was
useful at the time it was added, but it's not anymore), which will only
make our lives harder when we actually expect an event to be queued
(eg. in tests), so remove it.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2697>
There do indeed seem to be places in our own code that trigger grabs on
actors before they are realized. It was not the intention to change the
practical preconditions for GNOME 43, so make it an even lower minimum
that every caller ought to match: That the actor is attached to the stage.
Further constraining of these preconditions will have to wait until
branching for new development.
Fixes: 9c79c7234 (clutter: Only allow grabs to be created on realized actors)
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2670>
The bare minimum that we can ask to an actor before creating a grab
on it is that it is realized (and thus, attached to the stage). Bail
out if that is not the case when creating a grab.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2669>
The source field was removed from ClutterEvent with commit
b644ea1bcebfef2fb3ed4b6b7de602000cece33b because the preferred way of
getting the event actor is now to use the device/sequence actor from the
stage directly.
With crossing events it's not that easy though, as crossing events
explicitly have a source and related actor that doesn't have to be the
same actor as the device actor. Since we kept around the "related" field
there anyway, let's also introduce a "source" field in
ClutterCrossingEvent and return that actor when get_source() is called
on a crossing event.
Part-of: <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2551>
