Open rmlockwood opened 7 months ago
Thanks for the feedback! I've put this into the Future bucket for now, as we already have a lot on the boil for 18.0, but will review when we are doing issue triage.
In the meantime, note that you can set a hint as default in the touch layout editor:
Granted, I suppose it's tedious to manually do this for every base key with longpress.
There are some complications to consider, though.
There are cases with some of our keyboards where there are two rows of longpress keys. Would it be safe to assume you'd prefer the rightmost on the first row to be the default?
An even better question, in my mind: would it be better if the longpress keys flowed from right to left, instead of left to right as they currently do? Our current implementations are obviously LTR-biased, which is what's given rise to this problem.
In this case, if we know that the keyboard is for an RTL language...
we could have the first longpress key display at the top-right in both the touch-layout editor and in the live subkey menu... which would have the net result of the first subkey being at the top-right for RTL keyboards while remaining top-left for LTR keyboards.
Our current subkey default:
This discussion assumes you're relying on that last entry - using the "first" subkey. It's just... the system currently doesn't account for RTL perspectives when determining "first".
Yes, the rightmost being the default would be great for a RTL language keyboard. Having it flow right-to-left would be great.
From: Joshua Horton @.> Sent: Tuesday, March 5, 2024 10:12 AM To: keymanapp/keyman @.> Cc: R Lockwood @.>; Author @.> Subject: Re: [keymanapp/keyman] feat: make the hint the rightmost longpress key when the keyboard is a right-to-left keyboard (Issue #10916)
There are some complications to consider, though.
image.png (view on web)https://github.com/keymanapp/keyman/assets/25213402/00973c19-d9b4-4630-bf3f-822a948b5b71
There are cases with some of our keyboards where there are two rows of longpress keys. Would it be safe to assume you'd prefer the rightmost on the first row to be the default?
An even better question, in my mind: would it be better if the longpress keys flowed from right to left, instead of left to right as they currently do? Our current implementations are obviously LTR-biased, which is what's given rise to this problem.
In this case, if we know that the keyboard is for an RTL language...
image.png (view on web)https://github.com/keymanapp/keyman/assets/25213402/33e8bc00-992f-4899-a3f8-1aa65d58031f
we could have the first longpress key display at the top-right in both the touch-layout editor and in the live subkey menu... which would have the net result of the first subkey being at the top-right for RTL keyboards while remaining top-left for LTR keyboards.
Our current subkey default:
This discussion assumes you're relying on that last entry - using the "first" subkey. It's just... the system currently doesn't account for RTL perspectives when determining "first".
— Reply to this email directly, view it on GitHubhttps://github.com/keymanapp/keyman/issues/10916#issuecomment-1977887721, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABWCQCKP6SCQQ4X56WRFNJ3YWUZ3LAVCNFSM6AAAAABEEQZWPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZXHA4DONZSGE. You are receiving this because you authored the thread.Message ID: @.***>
Is your feature request related to a problem? Please describe.
It's great that the default hint is what is on the longpress keys, but having the default be the leftmost one of the longpress keys is opposite of what the user would want. The user will longpress and then scan or move right to left through the options.
Describe the solution you'd like
When the keyboard is for a right-to-left language, use the rightmost longpress key. When there are multiple (like more than 3) the bottom rightmost is the one I would want to be the default hint. This rightmost key is the one I'm judging to be the most frequently used and the closes distance for the user.
Describe alternatives you've considered
No response
Related issues
No response
Keyman apps
Keyman version
16
Operating system
No response
Device
No response
Target application
No response
Browser
No response
Keyboard name
No response
Keyboard version
No response
Language name
No response
Additional context
No response