Angle snapping tolerance functionality

[mohsenD98]

PR Description
The snapping to angles functionality was working, but the snapping tolerance (the distance within which the cursor would snap to an angle) was too low. This low tolerance made it difficult to snap accurately to angles, especially when digitizing without a mouse. The precision required to hit the right angles was cumbersome, causing a less intuitive experience for users.

Solution:
To address this, we added a new option that allows users to configure the snapping tolerance for angles. This change improves usability by giving users more flexibility in setting the snapping distance to their preference, making it easier to snap to angles accurately without requiring precise cursor placement.

Changes Made:

• Introduced a configurable snapping tolerance setting for angle snapping.
  • Narrow
  • Normal
  • Large
• Users can now adjust the snapping distance to better suit their needs.

This enhancement improves the overall user experience, especially when precision is important.

Image:

[qfield-fairy]

🎉 Ta-daaa, freshly created APKs are available for d0f8a2a: arm64-android

Other architectures

• arm-neon-android
• x64-android
• x86-android
• all access arm64-android
• all access arm-neon-android
• all access x64-android
• all access x86-android

[nirvn]

Alright, first, UI-wise, I think we need to make sure we have our text labels aligned vertically, which means you'll need to push add padding to pretty much everything there, i.e.:

Also, I think we've discussed this briefly but just as a recall, I think we should not close the popup when someone clicks on elements of the popup as I think it'd be quite likely a user would want to change more than one setting at a time.

Onto the actual functionality, I see there's a problem that needs resolving: when tolerance is set to largest, snapping doesn't occur when your coordinate cursor gets close to the last entered point. It's actually something that's happening even at normal snapping tolerance, but it's most visible when set at large.

Looking at the code now.

[nirvn]

Ouf, what's happening with the formatting here? Is it caused by the // comment next to the case forcing the column (:) to go onto next line? Let's fix that.

also, you should have case 1 and default both be together. The logic here is that default == normal. If we keep them separated, it's quite likely we'll end up changing one value and forget the other.

[mohsenD98]

Ah, yes formatting did this, Agreed 👍