Add ability to remove default input map

[Feniks-Gaming]

Describe the project you are working on:

Short game with input

Describe the problem or limitation you are having in your project:

Default input map is a good place to start some users but the fact that it cannot be renamed or deleted makes zero sense. It clutters the input maps with all the "ui_down" "ui_up" etc before it gets all the way down to user defined inputs.

Describe how this feature / enhancement will help you overcome this problem or limitation:

99% of time user wants to implement his own input and naming convention. Ability to remove all default input would be great at keeping input map with only input keys user is actually implementing in his/her game

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Like this but empty

Describe implementation detail for your proposal (in code), if possible:

Don't know probably the same way we can add and remove user define inputs.

If this enhancement will not be used often, can it be worked around with a few lines of script?:

You can work around it by suffering having all those inputs there for no reason and it works fine but there is no purpose to it.

Is there a reason why this should be core and not an add-on in the asset library?:

Yes it's very much core of a game engine and everyone uses input map when making new project.

[Calinou]

This would be a bad thing for accessibility, as those actions are required to benefit from keyboard-friendly navigation. See discussion in godotengine/godot#17210. However, we can collapse them by default and fade out their names to improve the input map editor usability. We should also add a tooltip to explain why built-in actions can't be removed.

[rainlizard]

According to discussion calinou linked, they're required. In which case it just comes down to cleanliness:

The point of the checkbox would be to hide them completely. Collapsing doesn't go far enough in my opinion.

[Calinou]

@rainlizard That works for me too. We could rename the checkbox to "Show Built-in Actions" and uncheck it by default, so that built-in actions are hidden by default. Most people won't need to change them anyway.

[Feniks-Gaming]

If they need to stay then I agree check box to hide them would be absolutely sufficient to solve the annoyance of them.

[Xrayez]

We could rename the checkbox to "Show Built-in Actions" and uncheck it by default, so that built-in actions are hidden by default.

#203 shares similarities due to filtering behavior, so likely both can be implemented at the same time.

[Jummit]

I think using a tree would be better design. Like this:

v UI Engine shortcuts

ui_x
ui_y

v Game shortcuts

jump

[Feniks-Gaming]

Rename UI to Engine UI to avoid any confusion

[FeatherAntennae]

Being unable to manage these actions was the first thing that bothered me about Godot. Enough that I learned C++ and found other things that bothered me and now I’m contributing and improving stuff! I propose we never fix this; it brings contributors. THE END.

Intro WALL OF TEXT™ (Skip for suggestions without the why)

Seriously though, coming from Unity or Unreal, it felt very weird to have all these actions without being given any latitude about it. Godot is the only engine I know of that forces these kind of things on their users. Sure, it’s also the only engine (to my knowledge) with such an extensive UI creation system but it’s hardly a reason not to improve. It's not the first time such a thread pops up, I agree there’s a lot of room for improvement and I don’t think we’re taking the right approach for it and having this in the proposal repo is a good opportunity to WALL OF TEXT™ myself into the subject.

Having a standard way to navigate and good accessibility in the editor is extremely important and it’s perfectly fine that we enforce them in the editor.

This section is not for the editor though, it’s for the games people are making. We shouldn’t be the ones to decide for them what is best, even if it’s true for 99.99% of cases. Right now, we’re saying that this is how everything should be forever, and it feels a bit too narrow minded to me.

People want a clean action list containing only what they created or what they need and we’re not allowing it right now. For this, filtering, searching and grouping are possibilities, but I think we should aim at giving more control to the users too. We should consider that some people might never use the default actions or any of the controls that require them. Some games might be made from the start with only a controller in mind and then default keyboard-only actions like “ui_focus_next” are really just clutter. What if the final product is on a console or a phone without keyboard?

One thing that I learned studying Human-Computer Interactions is that UI/UX are and will always be about compromises between good design directives and principles, what experience says is best, what research says is best, and real-world use cases, aka what users need.

It’s very easy to go with what seems like is the best thing for 90% of the time and suddenly end up with a zillion Linux forks and everyone missing a nice feature from someone else’s fork. In my opinion, in a situation like this, we should make it clear why we have these actions and why they’re good for accessibility, but we should also give the users the final word on the matter.

Short term suggestions that don’t require refactoring ALL THE THINGS:

People shouldn’t have to create an issue on GitHub to realize there’s a reason the default actions exist and can’t be removed. Currently, the actions are just there, and we can’t interact with them.

We should add the delete and edit buttons to the default actions, disable them and put a tool tip when the disabled buttons are hovered explaining why these buttons are disabled and why these actions are important. Even just “used by UI controls” would help. This would inform people on the subject and they won't have to go through GitHub or ask on Discord how to delete them just to get told: “you don’t”.

All icons would now also be on the same spot on the horizontal sections which will improve the flow of the list. Right now, the “+” button for adding a new key bind is at a different spot if it’s a custom action or a default one, because the default ones don’t have a delete button.
Allowing to toggle them as visible or not and using a less common prefix would also be pretty nice.

It’s also a bit weird that you cannot rename or delete the default actions, but that it’s allowed to delete all bindings in them. Sure, it helps not exploding the editor, but it also sends mixed message as to the purpose of keeping these actions.

Long term suggestion that requires refactoring ALL THE THINGS:

We could make it so there’s a property decorator specifically for input actions. Exposing them as editable in the editor would give a list of existing actions in a drop down that filters itself out as you type the name in while allowing to select one by click. Much better than just a text field where you copy and paste the name of an action and then use the name in the code.

Using this, UI controls that require the default actions (or would have missing features without them) could warn if a required action binding is missing, just like a kinematic body does when it doesn’t have a collision shape in its children. With the warning, we could maybe even allow generating an action with default values and bindings if the default one has been deleted. It would also allow people to remap them the way they see fit or rename the default actions to follow their own naming conventions.

As a bonus, we’d make it simpler to make a custom node that requires an action to do something as it would streamline the way to give the user a warning that it’s needed AND give the user a list of available actions to pick from without having to open the settings, go to the tab, find the right action, and copy-paste the name. (Think add-ons for a custom in-game debug console that requires a way to be toggled on and off or an add-on that adds a toggle-able vanity camera or anything like this.)

Another improvement, the actions could have both a name AND an id. This could allow people to rename default actions without breaking anything. Sure, we can’t stop people from fetching the names and hard coding their actions (like we’re doing right now), but with the property thing, we could at least give a good example. For the id, we could do that just like it was proposed for resources here

Lastly, we could keep the default actions in the list, but allow people to delete and rename them at will, giving a warning that some UI controls will require restoration or manual binding if used. A sub-menu and/or context menu could also give an option to restore/create all default actions again if wanted. This way people know why the actions are there and they’re told they should probably keep them, but they are also free to manage them if wanted.

[girng]

Eh, I view these as the "primitive input names", they never really bothered me. In fact, sometimes they can be useful. For example, rapid game prototyping or creating a bug report project. I can quickly use ui_left, ui_right, etc.

[SuperDIMMaX]

Bad idea remove this.
Just add button - remove all buttons keys. (or/and standart buttons).
If need not ui_up - just make alias... example button = {"UP":"ui_up "}... or var... or enum...
Removing this - break capability...

[Feniks-Gaming]

@girng @SuperDIMMaX ability to hide those inputs doesn't affect your prototyping they are still there but those of us who want them hidden can hide them your post is basically "This issue doesn't affect me so I don't want others to have easier life"

[AlexZan]

The main argument against this type of request is that these default input mappings are required for the ui. My argument against that is as follows:

Input Map, or anything for that matter should be opinionated, by default. Behaviour/Opinion should be contextual. For example, If I am making a simple 3d prototype, that has no interest in ui, and does not want the clutter of current default settings, it should not be forced.

If a developer is working on a project that requires the type of UI that the current default input map is made for, they can load it in from a list of default presets, or download/add it. There could eventually be several for different common game types.

Starting with a blank state will allow developers to have better focus and more organic growth to their project.

I am prototyping about 20 different projects, many of them have conflicts with the default input map. It should not be forced, but optional.

[FeatherAntennae]

@AlexZan I agree, the problem really is that these should have never been hard-coded as a necessity.

I understand that yes, they have been and changing that is going to break a lot of stuff, but it's hardly a reason not to try to make things better.

That's why I think we need to stop closing these kinds of proposals.

My wall of text up there contains a few ways to approach the problem and the more discussion we get around this, the higher the chances we find a good solution. It might be something minor to a lot of people, but having lots of minor frustrations always ends up as a major pain in the... User.

[Calinou]

That's why I think we need to stop closing these kinds of proposals.

We close proposals because they don't follow the template or are obviously lacking support, not because we personally dislike them. There's also no point in keeping duplicates around 🙂

Anyway, I still don't see an issue in the current default input map. In fact, the default naming scheme even suggests that input actions should be named with snake_case (per convention), which is a good thing in my book. You don't have to follow this convention, but doing so helps avoid mistakes when other people contribute to your project.

Several of the UX issues related to the input map editor are being solved in godotengine/godot#35819.

[FeatherAntennae]

@Calinou of course!
I was saying that more as a "let's keep trying to find a solution" not as "noooo, bad managers, no delete!" 😄

People keep asking for this and there were quite a few older issues in the main repo that kind of got lost or closed because no one was discussing or brought any ideas, and this has been going for a few years too.
I'm not blaming anyone for closing these 😅

Having this proposal in this repo is a good opportunity to actually discuss the problems and keep things organized, so it's a good step forward.

On a different note though, I think the UX changes in that PR are a huge improvement already on the communication side of things. We can all have different opinions on whether or not these default actions should be there, but I think these communication and usability changes were badly needed, so thanks!

[AlexZan]

If principals can be established, then there will be less need for these discussions. Ideally, every issue should develop a principal. If there is an issue it means a principal wasn't followed, or there is one lacking.

I propose out of this issue, the following: No feature should force defaults that are specific to just one of many use cases. Though it may provide it as an option, that can be enabled.

[aaronfranke]

We could implement the show/hide checkbox with a PackedStringArray of exceptions and checking the list via .has(), but first we would need godotengine/godot#32144 to be merged.