Rename "Control" key to "Ctrl" and add "_pressed" suffix to all InputEventWithModifiers properties/methods

[AaronRecord]

See #16863 (comment)

if (event->get_control()) {
...
}

becomes

if (event->is_ctrl_pressed()) {
...
}

Renames:

• KEY_CONTROL to KEY_CTRL
• MOD_CONTROL to MOD_CTRL
• InputEventWithModifiers:
  • Affixed _pressed to all modifiers
  • control to ctrl(_pressed)
  • renamed meta(_pressed)'s setters and getters to match the property name ([...]_metakey_pressed() -> [...]_meta_pressed())
  • get_ to is_ for modifiers' getters

On MacBook keyboards, Ctrl is often control, but I believe Ctrl is more common (the documentation literally calls it the Ctrl modifier, and most comments in the code say Ctrl) and more importantly won't get confused with Control nodes.

[madmiraal]

Looks good to me. Just one small nitpick below.

[akien-mga]

It would have been better for review purposes to split those changes into two PRs, the rename of Control to Ctrl is just one aspect of this PR which changes a lot of the InputEventWithModifiers API.

That being said, now that the work is done let's keep it this way.

I don't have a strong opinion on rename Control to Ctrl, but I'd just raise a comment that the name of keys doesn't necessarily match what's printed on the key caps... My laptop has "pg up" / "pg dn", yet we have KEY_PAGEUP, KEY_PAGEDOWN. A German keyboard has "Strg" for the control key. We also have KEY_ESCAPE when most keycaps have "esc" or "Esc" printed on them.

I do not think that we should rename KEY_ESCAPE so I just want to make it clear that the aim is not to have a 1:1 correspondence between key names and what's printed on key caps. Following a standard might be a better way to decide what should be used.

Now, if most are in favor of the rename I don't mind either way.

---

On the other proposed changes to InputEventWithModifiers, I haven't seen much discussion. I'm not sure it's worth it to add a _pressed suffix to all properties, isn't it clearly inferred by the description of InputEventWithModifiers? It's an InputEvent and it has modifiers, which can be Alt, Shift, Ctrl, etc.

I don't feel strongly either about this but someone needs to raise a comment to get at least some discussion going on the merits of the change ;)

[AaronRecord]

On the other proposed changes to InputEventWithModifiers, I haven't seen much discussion. I'm not sure it's worth it to add a _pressed suffix to all properties, isn't it clearly inferred by the description of InputEventWithModifiers? It's an InputEvent and it has modifiers, which can be Alt, Shift, Ctrl, etc.

My reasoning for this change was mostly because I thought adding _pressed would help the code read easier.

For example:

if (event->is_meta() || event->is_command()) {
    // ...
}

makes less sense to me than:

if (event->is_meta_pressed() || event->is_command_pressed()) {
    // ...
}

The first one sounds like it's asking if the event is meta or if the event is a command (whatever that'd mean), which might be a little confusing to someone new to the codebase/unfamiliar with the InputEventWithModifiers class, the _pressed makes it clear it's referring to the meta/command keys.

Also I think it's more consistent with Input.is_key_pressed(), which could be called Input.is_key() or Input.get_key() but I think Input.is_key_pressed is the most clear and easy to read.

[akien-mga]

Thanks!