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

Get default long press delay value from Android settings #559

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

syphyr
Copy link
Contributor

@syphyr syphyr commented Mar 14, 2024

The default long press delay value is set within Android's Settings --> Accessibility --> Touch & hold delay, so use that as the default value in Heliboard as well. Also, increase the max long press delay value to 1500 so that it matches the max value in Android's settings.

@syphyr
Copy link
Contributor Author

syphyr commented Mar 14, 2024

Here are the values in Android's settings for long press delay:
https://android.googlesource.com/platform/packages/apps/Settings.git/+/master/res/values/arrays.xml#643

The default long press delay value is set within Android's Settings -->
Accessibility --> Touch & hold delay, so use that as the default value
in Heliboard as well.  Also, increase the max long press delay value to
1500 so that it matches the max value in Android's settings.
@syphyr
Copy link
Contributor Author

syphyr commented Mar 14, 2024

Updated variable name

@Helium314
Copy link
Owner

increase the max long press delay value to 1500 so that it matches the max value in Android's settings

I see the reasoning, but at the same time it looks like there was no request for increasing the maximum to more than 700 ms.
Seeing these quite large values makes me wonder whether it really is a good idea to have such defaults. Do you know which value is the default setting for the Android system?

@syphyr
Copy link
Contributor Author

syphyr commented Mar 17, 2024

If Android's default settings are not changed, the default value is 500ms on <= Nougat and 400ms >= Oreo. The only reason I increased the max value to 1500ms is so that it would be able to match the maximum value in Android's settings. Most people would probably not change these default settings. The idea is to just be able to provide consistency between the keyboard and Android's system values.

@Helium314
Copy link
Owner

I had a while to think about this, and decided I do not want to change the default value. This PR will increase the value for every user who is using the default value by at least 100 ms, which is quite noticeable, and I expect to be unwanted by most users.

@syphyr
Copy link
Contributor Author

syphyr commented Mar 23, 2024

I had a while to think about this, and decided I do not want to change the default value. This PR will increase the value for every user who is using the default value by at least 100 ms, which is quite noticeable, and I expect to be unwanted by most users.

I understand your decision. I would also like to mention though that when the long press timeout of an application does not match the long press timeout of android's system settings, the following error can occur when quickly touching the UI:

https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-7.1.2_r39/services/core/java/com/android/server/wm/Session.java#339

On Android 7 the relative code is in Session.java and is later moved into WindowManagerService.java on newer versions of Android.

Edit: Although, this seems to only be affected when "dragging" objects

@Helium314
Copy link
Owner

https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-7.1.2_r39/services/core/java/com/android/server/wm/Session.java#339

This is inside performDrag, which I would (perhaps naively?) assume to be unused in the keyboard

@syphyr
Copy link
Contributor Author

syphyr commented Mar 23, 2024

https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-7.1.2_r39/services/core/java/com/android/server/wm/Session.java#339

This is inside performDrag, which I would (perhaps naively?) assume to be unused in the keyboard

yes, I guess the keyboard would not be affected by this since I dont see any "dragging" being used.

@syphyr
Copy link
Contributor Author

syphyr commented Mar 23, 2024

Maybe this could be revisited if this keyboard adds some kind of "floating" functionality.

@Helium314
Copy link
Owner

I agree, the floating window would definitely use drag functionality, and also a longer delay would make sense there.

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.

2 participants