Fix gesture picker misalignment by using constraint ratios

[theMr17]

Purpose / Description

The issue occurred due to a fixed 16dp margin around the outer circles, while the central arrow image scaled dynamically based on available space. This caused misalignment in smaller gesture picker sizes.

Solution:

• The outer circles' margins are now dynamically adjusted using constraint ratios (0.047 and 0.953), ensuring proportional scaling.
• This change maintains visual consistency across different screen sizes and orientations.

Fixes

• Fixes [BUG]: Gesture Picker screen (arrow is overlapping with circle)  #17348

Approach

Previous Behavior:

• Outer circle margins were hardcoded to 16dp.
• The central arrow image scaled dynamically, causing layout issues on smaller screens.

New Behavior:

• Instead of a fixed margin, outer circles now follow a constraint ratio:
  • 0.047 (4.7%) for the top margin.
  • 0.953 (95.3%) for the bottom margin.
• This ensures proportional spacing, adapting to different screen sizes while keeping the layout intact.

Note: A 4.7% margin from the edges of the layout preserves the 16dp margin in the original picker size.

How Has This Been Tested?

Portrait	Landscape

Checklist

• You have a descriptive commit message with a short title (first line, max 50 chars).
• You have commented your code, particularly in hard-to-understand areas
• You have performed a self-review of your own code
• UI changes: include screenshots of all affected screens (in particular showing any new or changed strings)
• UI Changes: You have tested your change using the Google Accessibility Scanner

[criticalAY]

Though bias should be avoided but here it seems like it fixes the issue and all views are using all 4 constraints so it won't cause an issue

[criticalAY]

Why this change? revert it

[theMr17]

Done.

[criticalAY]

Revert this change

[theMr17]

Reverted.

[theMr17]

Hey @criticalAY, thanks for review! Addressed your comments, please take a look.

[criticalAY]

Look OK to me

[BrayanDSO]

LGTM. Thanks

[Arthur-Milchior]

For some reason I can't squash merge. I wonder whether it's because there is a merge commit in this PR.

It'd be great if instead of adding more commit, you amended the previous commit. Now you can use git rebase --interactive HEAD~6 to put all in a single commit and then force push it.
Or potentially you could also pull ankidroid/main, reset softly to ankidroid/main and recreate a single commit with the commit message that should be added to our history. This way, I could merge it.

For future PR, you could just use git commit --amend or the "amend" option of whatever UI you use to create git commits, so that you change the commit instead of adding more commits

[theMr17]

Ah, seems like I messed up with the rebase.

[Arthur-Milchior]

Thank you very much @theMr17

Can you please let me know, are you applying to this year GSOC? I've not seen you mentioning you want to apply, but you came back to us just when the candidate phase started.
If you're not here for GSoC, then I'd really appreciate if you could wait until the end of the candidate phase to tackle new issues. We need to keep some "simple" issues for candidate, and spend our limited review time with them.
If you're applying with us, then wonderful, you're doing great contributions those past days. (Well, your contributions are great even if you're not applying)

[theMr17]

@Arthur-Milchior It's purely a coincidence that I resumed my contributions during the candidate phase. I'm not applying for GSoC this year, but I might be applying in the future. I completely understand the need to prioritize review time and simpler issues for candidates. I'll focus on wrapping up my currently open PRs and won't start anything new until the candidate phase concludes.

Thanks for your kind words!

[david-allison]

Hi there @theMr17! This is the OpenCollective Notice for PRs merged from 2025-03-01 through 2025-03-31

If you are interested in compensation for this work, the process with details is here: https://github.com/ankidroid/Anki-Android/wiki/OpenCollective-Payment-Process#how-to-get-paid

We only post one comment per person per month to avoid spamming you, regardless of the number of PRs merged, but this note applies to all PRs merged for this month

Please understand that our monthly budget is never guaranteed to cover all claims - the cap on payments-per-person may be lower, but we try to make our process as fair and transparent as possible, we just need your understanding.

Thanks!