Disable the conflicting iOS swipe-back gesture in the analysis

[r3econ]

• Disables the iOS swipe-back gesture to prevent it from conflicting with piece drag gestures on the board near the left edge
• Resolves Piece drag in analysis mode conflicts with iOS swipe-back gesture #2938

Demo

fix-swipe.mov

[ijm8710]

Hey @r3econ any chance it still preserves swipe back down low near the annotated moves? Not sure if that's possible (I think it is as I've seen some apps have backswipe at some heights but not others), but would prefer not to lose backswipe altogether if possible

[r3econ]

@ijm8710, not easily. If this ever becomes a priority, the right fix would probably be upstream in the chessground package. I think losing swipe-back is a reasonable trade, same as in puzzle and real-time game screens

[ijm8710]

Yeah I hear ya. Bouncing in and out of analysis boards is probably my most used action in the entire app so I wish there was a way to keep it some way but I undertand the importance to prevent the conflict

[veloce]

I intentionally made it that way because in the analysis screen there is no risk of losing time or making a wrong move because of the drag conflict.

If you have a conflict I reckon it can be annoying but at the same time losing the back swipe gesture is also annoying.

I am not sure which one is the most annoying tbh, but I am putting this on hold a little while as I don't want to rush on conclusions too fast here. This PR could be the place to gather feedback for this behaviour.

[ijm8710]

Veloce said this perfectly how I felt as well

I'm sure this is going to need some sizable adjustment or may even be fully unusable but I was chatting with chat gpt about the two conflicts

Originally, earlier in the pull request I suggested full region based logic where if you're vertically in the board zone, you disable swipe back and if you're above/below it, enable swipe back

Chat gpt agreed it would not be an easy pull request

But alternatively it thinks only allow swipe-back if:

• the gesture starts at the left edge AND
• it’s outside the board vertically
• That’s it. No fancy zones, no overlays.

I'm really not sure of the difference between the two ideas.

But curious if this code provides any inspiration whatsoever?

func gestureRecognizerShouldBegin(_ gestureRecognizer: UIGestureRecognizer) -> Bool {
    guard let view = gestureRecognizer.view else { return true }

    let location = gestureRecognizer.location(in: view)

    let isFromLeftEdge = location.x < 20   // standard edge swipe zone
    let isInsideBoard = boardFrameInView.contains(location)

    // Block only if user starts swipe from edge AND inside board
    if isFromLeftEdge && isInsideBoard {
        return false
    }

    return true
}

[isaacl]

Apologies if I'm misunderstanding, are we trying to decide if this nav behavior is good?

In many analysis contexts, a nav back loses data. iOS does not have a forward gesture.

Currently some left gutter piece drags work in round, do not always work in analysis, because of the nav capture.

Could move to two finger drag for back/forward as a future feature maybe.

[veloce]

The idea is to leave the normal nav behaviour in as many places as possible, because that is how iOS apps work. Thus disabling it only when really necessary: when playing a game.

If that happens during analysis, it is annoying, but it is not critical: you don't risk to lose a game. If you take a piece and it starts a backward nav gesture instead, you can cancel it before it happens. I personally never lost data because of that.

[isaacl]

@veloce I've accidentally swiped back more than once.

When that happens, the lines I was exploring are just gone.

Nav swipe should be available but not in places where it can be accidentally triggered and lose data.

Also, users probably spend most of their time in round. When they visit analysis, it looks similar to round. But it doesn't act the same. The same piece drag motion in analysis sometimes starts a nav swipe. Even once you get it, it's not trivial to grab the piece and without the nav.

IMO it is more important to be consistent within the app and we are not consistent here.

[ijm8710]

@veloce I've accidentally swiped back more than once.

When that happens, the lines I was exploring are just gone.

Nav swipe should be available but not in places where it can be accidentally triggered and lose data.

Also, users probably spend most of their time in round. When they visit analysis, it looks similar to round. But it doesn't act the same. The same piece drag motion in analysis sometimes starts a nav swipe. Even once you get it, it's not trivial to grab the piece and without the nav.

IMO it is more important to be consistent within the app and we are not consistent here.

I don't think disabling swipe back on that screen is the solution.

I think this is #1921 (comment)