When activated in modal, `translate`, `resize`, `rotate`, `shear` and
`edge_rotate_normal` use a different orientation than the set in scene.
This orientation needed to match since some of these modes can be switched
during operation.
The default orientation for these modes was `V3D_ORIENT_VIEW`.
And this changed when finishing the `translate` and `resize` to
`V3D_ORIENT_GLOBAL`.
But this could cause inconsistencies when inputting values from the
keyboard.
The solution now is to change the orientation when you change the mode.
---
Note: Although the user can expect the value entered to reflect the
orientation set in the scene, it would require a lot of changes and would
not be really useful.
In some cases functions were defined with arguments of different array
lengths in headers vs. implementations. This commit fixes some of the
cases I ran into, but probably not all of them.
As shown on the T85383, attempts are made to edit the precision mode key.
But that key was hardcoded.
That key now appears among the custom modal keymap items.
The transform code did not provide a 2d context to be used in 3d space.
The solution is to set all matrices for the screen space in these cases.
This commit also removes the dial3d drawing in these cases.
It was not correct anyway.
The transform modes `shrinkfatten` and `seq_slide` have a special way of
handling events.
They use modal events in a different way than expected.
Therefore, this commit adds special event handles for these modes and
removes the keymodal tips from the status bar.
These effects are already described in the header anyway.
Technically it shouldn't have any effect on these editors.
The key tips in the header can be misleading.
The effect it previously had was not intended.
With rBc0677b662f4b, we try to track all modal events in order to detect the
one corresponding to the release.
But modifier keys can mask the modal event and thus confirm realease ends up
being skipped.
This resulted in the T83387.
With this commit we now read the actual key drop value in the modal event.
This fixes T83387
The transform modifiers are confirmed by releasing any button.
Thus, the operation can be falsely confirmed if the button that launched
the operation is released after the modifier has been activated.
Previously the events that confirmed the modifiers were hardcoded.
An option to fix this would be to add custom confirmation keyitens for
specific modifiers. But this can be a bit confusing and would make the
modal keymap even bigger.
So the solution here is to skip the button that launched the operation
when confirming the modifier.
The two entries `TFM_MODAL_AUTOCONSTRAINT` and
`TFM_MODAL_AUTOCONSTRAINTPLANE` had the same name
displayed in the UI. The latter is now includes
"plane" in it's name.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D9474
The behavior of the incremental snap did not take into account the
relative dimensions of the window, which resulted in a different behavior
if the area height was greater than the width.
Approximately 141 changes of capitalization to conform to MLA title style.
Differential Revision: https://developer.blender.org/D8392
Reviewed by Julian Eisel
This was the behavior in old versions of blender.
During a transformation operation, when pressing a contrain key, the chosen
orientation is that of the scene.
If you press the same key, the orientation changes to Global or Local.
However, if you choose another contrain axis with the orientation changed,
the orientation does not return to the set for the scene.
It remains Global or Local.
Now when changing a contrain axis, no matter what the current orientation is,
it always returns to the scene orientation.
This fixes and reverts commit c7287ffaec
Due to hardcodded keys, the modifier for auto contrain plane did not
work with custom keymaps and was in conflict with other keyitems.
Its usability is also confusing since it cannot be used without
`MOD_PRECISION`
But instead of removing it, it is better to make this modifier compatible
with custom keymaps and keep the conflict.
This reverts commit 17905e89a7.
Fix T80429: Transform Tools cannot be cancelled
rB17905e89 better filtered the key items that should appear in the
status bar.
But it is very restrictive since canceling is still possible in other
cases.
# Conflicts:
# source/blender/editors/transform/transform.c
Keymaps must be customized by the user.
But this is not the case for hardcoded keymaps.
Also the repetition of hardcoded and user-defined keyitems may induce
the user to think they have made a mistake or it is a bug.
Differential Revision: https://developer.blender.org/D6454
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/editors/transform` module.
No functional changes.
Support custom-data correction based on surrounding geometry for all
transformation modes of the mesh transform operators.
The is the same logic used in Vert and Edge Slide.
In order not to change the current default behavior,
this property does not affect Vert and Edge Slide modes.
This caused an additional argument when exiting object modes
and many other low level functions which don't need to access context.
This simplifies fixing T77073.
This feature was a hack to prevent mmb select to print the orientation from menu in pre 2.80 versions.
Removing this feature as it is no longer an issue.
