thunderbird / thunderbird/thunderbird-android
Tap-to-scroll or Page turning for a better UX / UI on e-ink display
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 14k
- Forks
- 2.8k
- Avg merge
- 3d 3h
- Merged PRs (30d)
- 57
Description
Checklist
- I have used the search function to see if someone else has already submitted the same feature request.
- I will describe the problem with as much detail as possible.
- This issue only contains a request for one single feature, not multiple (related) features.
App version
6.400
Problem you are trying to solve
I use K-9 to read my e-mail on an e-ink tablet (Boox Max3) and an e-ink phone (Hisense A5).
Scrolling on an e-ink or e-paper display isn’t a great experience because it is slow, and leaves artifacts on the screen (like grey pixels remaining where black characters where printed)
Used to read my e-mails for years with a mutt client on GNU/Linux desktop, pressing space for viewing the next page is not a new thing, but with the lag of low fps display, it became a new necessity :-)
Suggested solution
Having a tap-to-scroll option for passing to the next page, like what you can find in pdf viewer (or basically any pager like more on *nix systems).
This gesture could to be complementary to the swipe to go to next/prev message.
Screenshots / Drawings / Technical details
Tap-to-scroll is exactly what it sounds like:
- By tapping on the right side (or bottom, or a button) of the screen, the page advances ~90%.
- By tapping on the left side (or top, or a button) of the screen, the page rewind ~90%.
Tap-to-scroll is useful to users on many devices beyond e-ink tablets. Some people enjoy it as a kind of page-turning function.
Indeed, this feature could be optional, disabled by default if community don't grok it.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source file or test is named in the issue. Start by locating the Android message-reading screen and its gesture or paging entry points, then determine how tap zones can coexist with swipe navigation. Done means optional right/bottom taps advance about 90% and left/top taps rewind about 90%, with the behavior disabled by default if required.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100