How to distinguish if a `GtkGestureDrag` ended normally or because of `gtk_event_controller_reset()`

Platform
1

If I have a GtkGestureDrag, how can i distinguish inside the "drag-end" signal handler between it being called because the dragging ended normally or because gtk_event_controller_reset() was called?

In both cases gtk_gesture_is_active() and gtk_gesture_is_recognized() return FALSE.

The use-case here is to be able to “reject” or cancel the drag gesture. I see that GtkGesture has a "cancel" signal for this, but it would be useful to know whether this happened directly from the gesture inside its other signal handlers.

2

GtkGesture::cancel is the generic way to get notified about that. I’m not sure if we could make this state API (or one that is not with a big “use only inside ::end/::cancel” note).

I understand though that peeking for low level signals is not great, subclasses can help abstract this away too. Maybe having a GtkGestureDrag::drag-cancelled that is mutually exclusive with ::drag-end might work better?

3

The more signals, the more ordering issues we have…

4

That would work better as otherwise the application would have to keep state around to distinguish these two cases, or having some boolean stored inside the gesture to distinguish that.

The gesture already stores the start point and end point, whether it’s active / recognized. It would seem like a useless complication for applications if all they need to know is already stored inside the gesture apart from the information whether the gesture finished successfully or was cancelled.

5

To give some more background, I’m currently storing the GtkGestureDrag in my application state and whenever I’m rendering I check if it’s active and in that case render a rectangle based on the start/offset the gesture keeps track of.

Then when the gesture is actually finished in drag-end I would like to make the operation connected to that gesture happen, but only if it was not cancelled. Right now I would need to keep another boolean around in addition to the gesture to do this, while all the other information I need is actually stored inside the gesture already.

6

Surely a gtk_gesture_was_cancelled() is easier than multiple signals?

1 Like
7

I was about to propose a was_cancelled() method. For GTK4 there’s even the option of adding a boolean was_cancelled argument to the drag-end signal, if we don’t want out of band methods.

1 Like
8

Yeah that’s what I meant with “or having some boolean stored inside the gesture to distinguish that”. That would work equally well for me and seems consistent with the other getters on the gestures.

9

I see 2 issues with that

  • The gestures have to keep a log of their past state. The signals and API center on the present most often.
  • Event sequences are reused, so it might happen that the gesture is replying about past touchpoint incarnations.

Probably they both are moot/easier if you just call this in code resulting from ::end/::cancel.

Although all this said, there’s gtk_gesture_get_sequence_state() that may be answering the question already here, with GTK_EVENT_SEQUENCE_NONE.

10

Extra argument on ::drag-end also sounds good. Indeed.

11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.