Ignore edge touches and bad swipes

[tadeubas]

What is this PR for?

Touch / Swipe handling

• Diagonal swipes: Swipes are now accepted only if the delta on one axis is 2 times greater than the other
• Long-hold: Long hold swipes (>750ms) are now ignored
• Edge touches: Discards touches near edges of adjacent regions

Other

• Refactored Page Prompt to reuse logic from its draw_proceed_menu
• Added title highlighting support for Tinyseed and Stackbit

Second PR from #771

Changes made to:

• Code
• Tests
• Docs
• CHANGELOG

Did you build the code and tested on device?

• Yes, build and tested on Embed Fire

What is the purpose of this pull request?

• Bug fix
• New feature
• Docs update
• Other

[codecov]

Codecov Report

❌ Patch coverage is 99.39394% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 97.39%. Comparing base (0f0bb13) to head (a2a8b80).

Files with missing lines	Patch %	Lines
src/krux/touch.py	97.87%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #797      +/-   ##
===========================================
+ Coverage    97.38%   97.39%   +0.01%     
===========================================
  Files           83       83              
  Lines        10544    10569      +25     
===========================================
+ Hits         10268    10294      +26     
+ Misses         276      275       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[odudex]

I feel some of these changes didn't come from real world issues and demands, but maybe a LLM prompt asking "what could be improved?". We have 18 files changed, increased driver complexity, ~200 lines added, different topics mixed.
I would like you to break these topics where there is a comma, "and", and "other", so we can evaluate clearly the problem each addition is solving and the eventual price we pay for it with added code.

[tadeubas]

Hey, just a heads-up - saying that I’m doing things "for the LLM" comes off a bit dismissive.

Also, can you clarify what exactly you’d like me to adjust? I asked previously here but didn’t get a response: #771 (comment). Without that context, I’m guessing what you want, which gets frustrating. Let me know the specific points you want addressed so I can handle them properly.

[tadeubas]

I feel some of these changes didn't come from real world issues and demands

Have you actually tested the code? And did you see my message in the DIY HW Retreat Telegram chat?

Code doesn’t have "feelings", I'm addressing real problems like unintended edge touches, accidental swipes (which happen to me a lot), and other wrong/strange behaviors. I've tested thoroughly, both manually and with unit tests (100% coverage from my changes).

I honestly don’t understand the concern. If there’s an "eventual price" we’re paying for the added code, please point it out clearly. I only see the real price we pay today with the existing issues.

[tadeubas]

It’s worth noting that PR, which covered a very rare use case, was merged adding 183 lines and no tests. In contrast, this PR handles a widely relevant issue and adds 184 lines, with a substantial portion dedicated to test coverage.

[tadeubas]

Ah, now I understand better. The MaixPy PR that was already accepted was titled "Inverted Color QR Code Detection", but it also altered the QR processing. So, to me, it appear to have "mixed things".

[tadeubas]

This PR can alleviate these types of problems:

[odudex]

Can you do a "before and after" video of the problem being solved?

[tadeubas]

This PR intentionally ignores edge/border region touches that on very small LCD devices are noisy and often unintentional (grips, thumb rests, slight misalignment). The UX improvement here isn’t something that’s easy to demonstrate, it’s something you feel when actually using the device.

The best way to evaluate the changes is to flash the PR (especially on a tiny display) and use it for a bit. The interaction feels noticeably more stable and predictable. Best screens to feel the difference are the ones with keypads, Tinyseed manual input and QR code transcription.