We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4598 - Please re-add SDL_EnableKeyRepeat(), and make sure it works on text input events
Summary: Please re-add SDL_EnableKeyRepeat(), and make sure it works on text input events
Status: ASSIGNED
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.0
Hardware: x86_64 Linux
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-13 21:04 UTC by Ellie
Modified: 2019-06-12 02:59 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Ellie 2019-04-13 21:04:20 UTC 
Please re-add SDL_EnableKeyRepeat(), and make sure it works on text input events. The problem is that with SDL_TEXTINPUT, one key stroke might cause multiple characters, or a key stroke might cause zero text characters, so doing this manually without breaking a corner case is pretty challenging without detailed internals knowledge of SDL2.

Why am I asking for this? On Android bluetooth keyboards can be unreliable not only in terms of lag, but also keys becoming "stuck" for half a second. Key repeat is seldomly REALLY needed even when typing text (as opposed to games where it's even less needed), so I want to provide a simple option to disable it. However, I find myself unable to do so because SDL_EnableKeyRepeat() was ripped out in SDL 2 and never reintroduced, and all the internet help text suggest hacking around key up/down events with manual tracking (which in itself is ugly) and which doesn't help me with the text input side of things.

I agree this is quite a niche use case but I'd say for getting accessibility right for all cases for less gamey apps, this option isn't that unimportant
Comment 1 Ellie 2019-04-13 21:08:48 UTC 
As for backspace and arrow keys, it wouldn't be entirely useless to be able to leave key repeat for them on since that's the only keys where people really expect it. (and which are also used comparatively rarely enough that an unintended repeat isn't as disruptive - still is, but not as bad) But the option would still be useful to me without this, since I'd consider it easier to reintroduce manual repeat for these keys than to reliably filter it out of text editing events myself for all corner cases
Comment 2 Sam Lantinga 2019-06-12 02:59:34 UTC 
We'll look at this post-2.0.10. Thanks!