How to check if a keypress is associated with text input?

[airstruck]

Inside a keypress event handler, I want to check if the keypress is also likely to trigger a text input event.

Under SDL, this could be done by checking the high bit of the SDL_Keycode in keysym.sym; if it's set, the key does not produce a unicode character by itself[1], and I can assume that it's not associated with text input. If it's not set, but any modifier keys besides shift are pressed, I can also assume that it's not associated with text input. Otherwise, the keypress will probably generate a text input event. This might not be foolproof, but should cover the majority of cases, leaving a manageable amount of corner cases to contend with (I hope).

Is there any way to check whether a key would produce a unicode character under Love, similar to checking the high bit of keysym.sym under SDL? If not, is there a workaround or a better way to test whether keypresses are associated with text input?

If this is not currently possible, could that information be exposed by adding a parameter to love.keypressed containing the unicode character that would be produced by pressing the key by itself, or nil if the key doesn't produce a unicode character?

[1] - https://wiki.libsdl.org/CategoryKeyboard

[slime]

Doing what you suggest won't be accurate. For example, alt+u, shift+o on my OS produces 4 key presses, 2 of which would be considered text input-causing by you. But it produces 1 text character: Ö.

Key presses just don't map 1:1 to text input, no matter what you do. What use-case do you have in mind?

[airstruck]

For example, alt+u, shift+o on my OS produces 4 key presses, 2 of which would be considered text input-causing by you.

The key presses would be alt, u, shift, and o, correct? I think only one of them would be considered text-input-causing under the plan I had; alt and shift won't produce unicode characters, u is ignored because alt was also pressed at the time, so only shift-o counts, and incidentally that does end up producing text input, so it should work, if only by accident.

Even so, the detection could probably be improved by watching for Love's equivalent of SDL_TextEditingEvent (forgot the name for it). I don't need it to work perfectly, just need it to be reasonably accurate more often than not.

What use-case do you have in mind?

I want to stop certain event handlers from doing what they would normally do under certain conditions when it looks like the keypress is likely to be connected with text input, at least in the most obvious cases (ie, an 'x' keypress with no modifiers is very likely text input, and an 'f1' keypress is very likely not text input).

[slime]

I want to stop certain event handlers from doing what they would normally do under certain conditions when it looks like the keypress is likely to be connected with text input, at least in the most obvious cases (ie, an 'x' keypress with no modifiers is very likely text input, and an 'f1' keypress is very likely not text input).

What's a situation where that would happen in practice? Do any other programs do that?

The standard way to do key presses and text input in all operating systems and programs I know of is to accept the text input events given by the OS when there's a text box in focus, otherwise the key presses have program- or OS-specific meaning. System keys, as well as special modifier keys combined with regular key presses won't generate text input in the first place.

[airstruck]

Suppose you map the 'q' and 'escape' keys both to exit the program. When the user presses 'q' or 'escape' the program should exit under normal conditions. Now the user focuses a text box and starts typing, and types a 'q'. I don't want the program to exit, I want the text box to trap this keypress event, because it's connected with text input. But if the user hits 'escape' while the text box is focused, I still want the program to exit, because the 'escape' keypress was unrelated to text input.

[binaryeye]

Is there any reason you can't have separate states, each with their own input handling?

[zorg]

As binaryeye said, you would usually use separate states, one for "global, or just program controlling" behaviors with what you make keypresses do, and in another, you just don't detect keypresses at all, and rather, use the textinput callback. (Then again, OSes like to over-complicate input handling a lot, depending on things you wouldn't even think mattered... and unicode isn't flawless either, so there's that...)

[airstruck]

I'm not sure what's being suggested exactly.

To expand on the example I gave earlier, let's say this is all happening in one gamestate, an options screen with some text boxes, sliders, check boxes and so on. The 'escape' and 'q' keys were mapped by the user in a config file, the program doesn't know what keys will exit the program until that config file has been loaded. I want to be able to figure out programatically if those keys are part of a text input event so that when one of the text boxes is focused, we can ignore keypresses that are part of text input, allowing the user to type a 'q' into the box without the program closing.

Maybe I'm just being dense, but is the suggestion to use separate states really relevant to this scenario?

The approach I'm taking right now is to trap all keypresses when the text box is selected, which seems to be what people are suggesting, but this is really not satisfactory. If the user has assigned functionality to certain keys unrelated to text input, it feels like they should still do their thing when the text box is focused (as in, the program does not feel like it is responding as it should).

[zorg]

I'm not sure what's being suggested exactly.

Let's take your post apart a bit, okay?

[quote="airstruck"]To expand on the example I gave earlier, let's say this is all happening in one gamestate, an options screen with some text boxes, sliders, check boxes and so on. The 'escape' and 'q' keys were mapped by the user in a config file, the program doesn't know what keys will exit the program until that config file has been loaded. I want to be able to figure out programatically if those keys are part of a text input event so that when one of the text boxes is focused, we can ignore keypresses that are part of text input, allowing the user to type a 'q' into the box without the program closing.[/quote] >When one of the text boxes is focused
You don't need to figure that bit out programatically, since i assume you keep a flag inside the text box objects or somewhere, denoting that one of them is "currently active (for keyboard input)". The problem then becomes: Only detect non-alphanumeric keypresses outside of textinput, which can be done like so:
[code]-- example
state:keypressed(key,scan,rep)
for i,v in ipairs(keymap)
if k == i and not alphanum(i) then -- the function returns true if the parameter is not the [a-zA-Z0-9] keycodes.
-- do stuff
end
end[/code] That's one way of solving it.

Maybe I'm just being dense, but is the suggestion to use separate states really relevant to this scenario?

Only marginally, if one state could only use one type of input, either text or key. That was my original idea; but since this is not your case, my previous solution is moot now.

The approach I'm taking right now is to trap all keypresses when the text box is selected, which seems to be what people are suggesting, but this is really not satisfactory. If the user has assigned functionality to certain keys unrelated to text input, it feels like they should still do their thing when the text box is focused (as in, the program does not feel like it is responding as it should).

Okay i think i get what you mean, like, shift+left and right arrows for selecting a part of the inputted text, and ctrl+c x and v for other non-text inputting stuff. I get it.
You could buffer the keypresses, and when they match a pattern you have defined to a "function" like copying (ctrl first, c second, where the one before the next is always held (as in, a keyreleased didn't happen for that key)) then you call that instead of appending anything to the input.
The issue with this approach is that you'd either need to "delete" back the textinput callback's additions (if you can't prevent it for reasons), or to not concatenate the input to the textbox' string (which would be the preventative route). However, not all pattern combinations might trigger a textinput call at all, so the deleting back way is, in my untried opinion, unreliable; that said, i might be wrong on that, and it might work _consistently_.

[airstruck]

The issue isn't that I want to prevent text input in some situations; a ctrl-c press won't generate a text input event anyway. I want to treat any text input event the same no matter what. What I want to do is treat keypress events differently, based on whether they are (most likely) associated with text input or not. If a keypress is not associated with text input, like 'escape', I want it to always behave the same. If a keypress is associated with text input, like 'q' with no modifiers, I want to suppress the default behavior when a text input has focus.

This should be possible under SDL, because key events report the unicode character associated with the key (if any). As far as I can tell this is not possible under Love, because that information is never exposed. Exposing that information could be done in a simple and backwards-compatible way by adding a property to the keypress callbacks. This is useful information, and I don't see any reason why we should not have access to it, even if there is a better solution to this particular problem (and so far I'm not convinced there is).