That's the most common one we've been using for the general editor, and while the script editor
also supports Ctrl+Y, it should have lower priority.
In theory this code should make both be supported the same but for some reason the general editor
only seems to use the first entry (the script editor does support both).
This removes hardcoded actions from things like LineEdit and TextEdit.
Previously, things like copy, paste, etc were all hardcoded to Ctrl+C, Ctrl+V, etc. They could not be changed. This allows the possibility of them being changed, by making them use the action map. This has the added benefit of greatly simplifying the input handling logic in those controls. The logic which was previously in a huge and hard to follow switch statement has been extracted to individual methods.
This adds the ability to add overrides for built-in actions (i.e. ui_*) in the editor. Also added a number of additional built-in actions for various text-related actions, gui-generic actions (like copy and paste) and graph-related actions (duplicate nodes), etc. Moved the definition of input actions to input_map, rather than in project_settings so the editor can make use of these actions as well.
No longer use emscripten functions for gamepads, implement them as
library functions in library_godot_display.js instead.
This allows us to do a better job at "guessing" vendorId, productId, OS,
etc. thus allowing us to better find the remapping for the controller.
In the core input handling code we have checks to make sure that if axis
rapidly change sign we inject mid-points to release any pending inputmap
action.
The function though, did not correctly insert the mid-point causing
dpads mapped to an axis that behaves like tri-state buttons (-1,0,1) to
not be released correctly.
This commit fixes that by including in the check the case where the axis
swtiches from abs(1) to 0.
Happy new year to the wonderful Godot community!
2020 has been a tough year for most of us personally, but a good year for
Godot development nonetheless with a huge amount of work done towards Godot
4.0 and great improvements backported to the long-lived 3.2 branch.
We've had close to 400 contributors to engine code this year, authoring near
7,000 commit! (And that's only for the `master` branch and for the engine code,
there's a lot more when counting docs, demos and other first-party repos.)
Here's to a great year 2021 for all Godot users 🎆
Added additional param to action related methods to test for exactness.
If "p_exact_match" is true, then the action will only be "matched" if the provided input event *exactly* matches with the action event.
Before:
* Action Event = KEY_S
* Input Event = KEY_CONTROL + KEY_S
* Is Action Pressed = True
Now:
You can still do the above, however you can optionally check that the input is exactly what the action event is:
* Action Event = KEY_S
* Input Event = KEY_CONTROL + KEY_S
* p_exact_match = True
* Is Action Pressed = False
* If the Input Event was only KEY_S, then the result would be true.
Usage:
```gdscript
Input.is_action_pressed(action_name: String, exact_match: bool)
Input.is_action_pressed("my_action", true)
InputMap.event_is_action(p_event, "my_action", true)
func _input(event: InputEvent):
event.is_action_pressed("my_action", false, true) # false = "allow_echo", true = "exact_match"
event.is_action("my_action", true)
```
Made InputEvent as_text() return a readable and presentable string. Added to_string() overrides for each which returns a 'debug-friendly' version which is not as presentable but provides more information and in a more structured fashion. Use as_text() for UI display scenarions and to_string() for debug cases
Made serialization of Command optional. If command is serialized, Control (On Win/Linux) or Meta (on Mac) are not.
Example use case: You are on Windows and you set a shortcut to be Control + E. This would serialize as Command=true and Control=true. If you then run this project on Mac, you would need to press Command AND Control to activate the shortcut - which is not what is intended. Now, you can set store_command to true, and it will only serialize to Command = true (no Control serialized). On Windows, this means Control. On Mac, it means only command.
A new `env.Run` method is added which allows to control the verbosity
of builders output automatically depending on whether the "verbose"
option is set. It also allows to optionally run any SCons commands in a
subprocess using the existing `run_in_subprocess` method, unifying
the interface. `Action` objects wrap all builder functions to include a
short build message associated with any action.
Notably, this removes quite verbose output generated by `make_doc_header`
and `make_editor_icons_action` builders.
Semicolons are not necessary after function definitions or control flow
blocks, and having some code use them makes things inconsistent (and
occasionally can mess up `clang-format`'s formatting).
Removing them is tedious work though, I had to do this manually (regex
+ manual review) as I couldn't find a tool for that. All other code
folders would need to get the same treatment.
I couldn't find a tool that enforces it, so I went the manual route:
```
find -name "thirdparty" -prune \
-o -name "*.cpp" -o -name "*.h" -o -name "*.m" -o -name "*.mm" \
-o -name "*.glsl" > files
perl -0777 -pi -e 's/\n}\n([^#])/\n}\n\n\1/g' $(cat files)
misc/scripts/fix_style.sh -c
```
This adds a newline after all `}` on the first column, unless they
are followed by `#` (typically `#endif`). This leads to having lots
of places with two lines between function/class definitions, but
clang-format then fixes it as we enforce max one line of separation.
This doesn't fix potential occurrences of function definitions which
are indented (e.g. for a helper class defined in a .cpp), but it's
better than nothing. Also can't be made to run easily on CI/hooks so
we'll have to be careful with new code.
Part of #33027.
Which means that reduz' beloved style which we all became used to
will now be changed automatically to remove the first empty line.
This makes us lean closer to 1TBS (the one true brace style) instead
of hybridating it with some Allman-inspired spacing.
There's still the case of braces around single-statement blocks that
needs to be addressed (but clang-format can't help with that, but
clang-tidy may if we agree about it).
Part of #33027.
Using `clang-tidy`'s `modernize-use-default-member-init` check and
manual review of the changes, and some extra manual changes that
`clang-tidy` failed to do.
Also went manually through all of `core` to find occurrences that
`clang-tidy` couldn't handle, especially all initializations done
in a constructor without using initializer lists.
It changed name as part of the DisplayServer and input refactoring
in #37317, with the rationale that input no longer goes through the
main loop, so the previous Input singleton now only does filtering.
But the gains in consistency are quite limited in the renaming, and
it breaks compatibility for all scripts and tutorials that access
the Input singleton via the scripting language. A temporary option
was suggested to keep the scripting singleton named `Input` even if
its type is `InputFilter`, but that adds inconsistency and breaks C#.
Fixesgodotengine/godot-proposals#639.
Fixes#37319.
Fixes#37690.
The 204 and 205 are the older, SDL 2.0.4 and 2.0.5 compatible mappings,
but since all new mappings have only been added to the main
gamecontrollerdb.txt which overrides the older entries, it doesn't make
much sense for us to keep the old databases.
We do not support the SDL2 half axes and inverted axes features from
gamecontrollerdb.txt, but this only impacts the specific controllers
which can use those features, the rest are parsed and used properly.
As for godotcontrollerdb.txt, it doesn't make sense for us to maintain
our own custom mappings instead of submitting them upstream. The only
exception is the Javascript and UWP platforms for which no bindings are
available upstream, so we keep those entries.
Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
