Move keybinding settings to (Lua-based) setting menu

[y5nw]

#15614 (comment)

Alternative to #15152.

Due to merge conflicts, please merge this after #14964.

• Goal of the PR
  This PR removes the dedicated settings menu for keybindings and instead adds the keybinding settings to the "Keyboard and mouse" section in the settings menu.
• How does the PR work?
  This PR introduces a button_key formspec element for capturing key inputs. This element is used in the Lua-based settings menu.
  The aux1_descends, doubletap_jump, and autojump options (which were also included in the keybinding form) can be found in "Controls" -> "General".
• Does it resolve any reported issue?
  • Fixes Redo change keys dialog #11209
  • Fixes Cinematic Camera is not in the keybindings menu #15729
  • Fixes Allow using the delete key as a keybinding #9602
  • Fixes In-game controls configuration does not detect collisions wth minetest.conf-only or hardcoded keys #3847
  • Fixes Being able to use middle Mouse button (button 3 aka scroll wheel) for controls #4211
• Does this relate to a goal in the roadmap?
  2.3 UI Improvements.

To do

This PR is ready for review.

• Implement button_key element.
  • Send event on release instead of on press.
• Add button to delete keybinding.
• Implement setting callback.
• Add sections to the keybinding list.
• Implement checks for keybinding collisions.

How to test

See #15152.

[SmallJoker]

Unfortunately this layout crops a few texts on smaller screens or window sizes. Although I don't think this can be fixed easily with the current formspec design. Just mentioning.

Meanwhile in master:

[y5nw]

Unfortunately this layout crops a few texts on smaller screens or window sizes.

I tried #15791 (comment). It does not crop the text, but it looks worse IMO, so I reverted it.

IMO it might be better to change the setting menu to use up the full screen/window space, which will (in general) create less problems for setting entries with two columns; although that would be out of scope for this PR.

[grorp]

Thank you for working on this.

Suggestions:

• The menu feels like it's not using the available vertical space well enough. I have to scroll a lot to see all the keybindings. Current layout:
  
  I think something like this would be an improvement (button height reduced to 0.6, spacing reduced heavily as well):
  
  (The "info" buttons would need to be put in again of course)
  EDIT: in hindsight, this is too cramped, see newer proposal below instead

• It's impossible to set a keybinding to mouse buttons, even though dig/place are listed and show them correctly

• It might make sense to put the keybinding section below a new sub-heading

[y5nw]

(button height reduced to 0.6, spacing reduced heavily as well):

The height of 0.8 is taken from other elements, so I would like to keep it this way for consistency.

I would personally prefer having a dedicated tab with a table of keybindings, but this does not seem to fit well into the way the setting form is currently designed.

It's impossible to set a keybinding to mouse buttons, even though dig/place are listed and show them correctly

Fixed in 33adc71:

(Actually I just noticed that this crashes the client if one tries to change the keybinding in-game; I need to look into this.) (Edit: should be solved now)

It might make sense to put the keybinding section below a new sub-heading

Done in cfaf84d.

[grorp]

Fixed in 33adc71: [screenshot]

Thank you, that looks good.

The height of 0.8 is taken from other elements, so I would like to keep it this way for consistency.

Reducing the height would indeed make things look more inconsistent. It could be a significant improvement in this case though. The amount of hidden pixels (the amount of scrolling necessary to see all the keybindings) was reduced by about 40% in my test (from 3711 to 2185). Maybe it would be possible to argue that buttons that usually only show a single letter don't need as much space :)

Since #13282, the keybinding menu also serves the purpose of informing the user about the controls, so being able to get a quick overview is useful.

Some of the keys listed at the very bottom are actually quite useful, like the viewing range and camera mode keys, so you'd want users to scroll all the way. On a side note, it might make sense to move these three further up.

I would personally prefer having a dedicated tab with a table of keybindings, but this does not seem to fit well into the way the setting form is currently designed.

It indeed doesn't. However, what you could do (not saying you should) is moving the keybinding settings to a separate dialog again, just in Lua instead of C++ this time. This would also allow the keybindings to use the full available screen space.

[SmallJoker]

Fixed in 33adc71:

Why exactly do we need this additional dialogue? Could we instead listen to mouse/keypad events as well to shorten the following steps ...

1. Click the settings button to opening the "single key change menu"
2. Selecting the right item in the dropdown
3. Pressing the button to capture a key || or select the mouse button in the dropdown
4. Close the menu

... to this:

1. Click the settings button to listen to any input.

[y5nw]

Why exactly do we need this additional dialogue? Could we instead listen to mouse/keypad events as well to shorten the following steps ...

The main issue was that I could not figure out how to cleanly handle mouse buttons with the keybinding button. I have a solution now (and committed) so I reverted the dialog.

Side note: We will likely still want a dialog for #15934, but we can leave it to that PR instead of here.

[y5nw]

I hope the description for Quicktune keys is correct? (I have never used quicktune before)

[grorp]

(I don't know either)

[grorp]

The new changes look good 👍

[grorp]

Looks good 👍

Thank you for working on this!