Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove separate longpress timeout for shift (caps lock) #924

Merged

Conversation

devycarol
Copy link
Contributor

@devycarol devycarol commented Jun 27, 2024

This patch removes the separate longpress duration attribute for the shift key altogether. I believe it's not useful, as I opine in the issue below. The only thing I'm side-eyeing is that "config_accessibility_long_press_key_timeout". I don't know the circumstances in which that value (3000) is used, but it's the only possible case where that hard-coded shift-lock duration is less than the general one.

Maybe there should be a special accessibility case where the shift-lock duration is set to 1200? I don't know.

Resolves #923

@devycarol
Copy link
Contributor Author

Upon further inspection, that 3000 might not have even been overruled by the 1200. But I haven't tested this.

@Helium314
Copy link
Owner

Making the time related to longpressTimeout definitely makes sense. I'm not sure about the no-multiplier-needed though.
Did you test / compare in normal keyboard use? I can imagine a multiplier of 1.5 or 2 might be a good idea (at least on a very short test my 180 ms longpressTimeout felt a little too short)

Upon further inspection, that 3000 might not have even been overruled by the 1200. But I haven't tested this.

You can just add a log entry in an appropriate plance, or use debugging. It's currently using 1200.

@devycarol
Copy link
Contributor Author

Do you know how to enable that "accessibility mode?" I don't.

@Helium314
Copy link
Owner

Ah, that weird thing. I had tried, assuming it's somehow related to Android accessibility settings (because the AccessiblityManager system service is used), and failed.

@devycarol
Copy link
Contributor Author

Yeah, odd that you'd have a 3-second touch-hold delay for anything. That could make accidental dismissals pretty frustrating (but again, I don't know how it works.)

Would you like me to put a 1.5x multiplier for the shift key timeout?

@Helium314
Copy link
Owner

Would you like me to put a 1.5x multiplier for the shift key timeout?

I would somewhat prefer it, but I'll leave it to you and will merge if you prefer to keep it without multiplier.
If the new timeout is too short, I guess someone will open an issue anyway.

@devycarol
Copy link
Contributor Author

devycarol commented Jun 30, 2024

Mind if I also apply that multiplier to the symbols long-press for the numpad? I find myself agreeing that it's warranted for the shift key, and I think it'd be good for that one as well.

@devycarol
Copy link
Contributor Author

If yes, ready for merge.

@Helium314
Copy link
Owner

Mind if I also apply that multiplier to the symbols long-press for the numpad? I find myself agreeing that it's warranted for the shift key, and I think it'd be good for that one as well.

Agree, this makes sense.

@Helium314 Helium314 merged commit 05e9af9 into Helium314:main Jun 30, 2024
1 check passed
@devycarol devycarol deleted the respect-long-press-setting-for-shift branch July 6, 2024 04:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Long-press for 'Shift' should respect the longpress timeout setting
2 participants