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

[pgimeno]

A fairly reasonable way to distinguish keypresses that generate text input (one that I'm using in my WIP 0.8 emulator) is:

Code: Select all

  exceptions = { space = true }
  if #key == 1 or #key == 3 and key:sub(1, 2) == "kp" or exceptions[key] then
    -- it's a key that generates text input
  else
    -- it's not
  end

(Edit: that's pseudocode, of course)

[airstruck]

A fairly reasonable way to distinguish keypresses that generate text input

Thanks for the suggestion, it beats mapping every single key (that was going to be my last resort). I guess it will need more exceptions for some weird keypad things like kp00, kp000, kp&&, kp||. It will also need more maintenance for future updates, for example if 'kp ' changes to 'kpspace' at some point. It's not as clean as having that extra bit of information available in the callback, and I suspect it won't handle unknown keys as well as the other solution would, but it should work for now. I'll open a ticket in the issue tracker later.

[davisdude]

Have you entertained the idea of having a variable that controls whether or the shortcut will work or not? In code:

Code: Select all

local isCurrentlyEnteringText = false

function textBox:enter()
    isCurrentlyEnteringText = true
end

function textBox:exit()
    isCurrentlyEnteringText = false
end

function love.keypressed( key )
    if not isCurrentlyEnteringText then
        if key == 'q' or key == 'escape' then love.event.quit() end
    end
end

It's kind of ugly, but if you could fix that if you tried.

[airstruck]

I might not be doing the best job of explaining the situation. I'll try to outline it.

- The user can bind keypress combinations to actions. For example, the user could bind ctrl-s to save, f1 to show help, and backtick (tilde) to show a console. The program has no way of knowing in advance what keybinds the user will set up.

- The user can press keys on his keyboard. Some of these key presses will result in text input events, like the backtick key. Others will not, like the 'f1' key, or the 's' key when ctrl is also pressed.

- Text boxes exist, which can be focused by clicking on them, and unfocused by clicking somewhere else.

When a text box is focused, any keypresses that generate text input events, like the backtick key, should not trigger any action the user may have bound to that key. You want to be able to type a backtick in the text box without the console opening. However, any keypresses that do not generate text input should still trigger any action the user bound to them. You always want to be able to press f1 for help, or ctrl-s to save, regardless of whether a text box has focus.

What I'm trying to do is predict with a reasonable degree of accuracy whether a keypress will generate a text input event, so that focused text boxes can trap keypress events that were associated with the user entering text, while allowing other keypress events to propagate.

SDL provides a critical piece of information that supports this in a pretty clean way. That information is not exposed to Love. Without that information, we have to either hardcode a list of every key that produces text input events when pressed by itself, or resort to workarounds like what pgimeno suggested, which involves looking at information that is only tangentially related and may change in future versions (like whether the name of the key is one character long, or three characters long and begins with 'kp', or appears in a list of corner cases, or whatever). These solutions get the job done, but are more or less hacks compared to having the specific information we're looking for available.

[zorg]

- The user can bind keypress combinations to actions. For example, the user could bind ctrl-s to save, f1 to show help, and backtick (tilde) to show a console. The program has no way of knowing in advance what keybinds the user will set up.

- The user can press keys on his keyboard. Some of these key presses will result in text input events, like the backtick key. Others will not, like the 'f1' key, or the 's' key when ctrl is also pressed.

- Text boxes exist, which can be focused by clicking on them, and unfocused by clicking somewhere else.

With you so far.

When a text box is focused, any keypresses that generate text input events, like the backtick key, should not trigger any action the user may have bound to that key. You want to be able to type a backtick in the text box without the console opening. However, any keypresses that do not generate text input should still trigger any action the user bound to them. You always want to be able to press f1 for help, or ctrl-s to save, regardless of whether a text box has focus.

My last message was related to this though, maybe i couldn't explain my idea good enough either

One thing i'd need to mention is that, though that part on the wiki was clobbered for some reason, 0.8.x did give back the unicode value as a parameter in love.keypressed, so that could be one route to ask for it to be passed in again.

For how to implement around it, the more i think about it, is hard, since there's no guarantee on the order of callbacks being fired in the event loop in love.run, so even implementing a filter in love.keypressed may not work if love.textinput gets fired first in the same cycle... not to mention that more than one of them can occur as well.

[pgimeno]

I know this is very old, and some people will probably want to kill me for necroposting, but just in case it turns up in some search, here's my solution: https://love2d.org/forums/viewtopic.php?f=4&t=87628

Maybe airstruck is still interested in implementing this in Luigi, after all Pinging, just in case:

[...]