Default Keymap Update: Improve tool access using Alt-LMB #83689

New Issue

Campbell Barton · 2020-12-12T04:53:42+01:00

Campbell Barton commented

2020-12-12 04:53:42 +01:00

Use Alt-LMB to improve tool-access (when MMB emulation is used, we can't enable this).

For LCS: Alt-LMB executes the tool without needing to use the gizmo.

  (we keep drag threshold as it's needed for detecting selection).

For RCS: Alt-LMB sets the cursor.

  (this allows us to remove the drag threshold on LMB - it always activates tool immediately).

Conflicts

Regarding use of Alt-LMB, see #69323 (Remove/Update "Emulate Middle Mouse" preference) for possible conflicts.

Open Topics

Some tools use the Alt key - such as shrink-fatten.


Possible solutions:

Modal operators that use Alt will have to ignore the alt key on tool activation, then detect it on release and press.
The alt key behavior could be inverted when it's used for activation.
Requiring Alt-LMB to set the 3D cursor when tools are activated might not be preferred by some users.

Possible solutions:

Keep the drag threshold for the tweak tool (perhaps all selection tools), so by default LMB-click places the cursor.
Have a preference to keep the current behavior - which uses a drag threshold to allow cursor placement and tools that drag.
Does this apply to other editors? time-line editors with tools (currently only the sequencer). Most likely placing the current frame with Alt-LMB isn't desirable, so we could opt-out of this in some cases (needs some further investigation).

Use Alt-LMB to improve tool-access (when MMB emulation is used, we can't enable this). - For LCS: Alt-LMB executes the tool without needing to use the gizmo. ``` (we keep drag threshold as it's needed for detecting selection). ``` - For RCS: Alt-LMB sets the cursor. ``` (this allows us to remove the drag threshold on LMB - it always activates tool immediately). ``` ### Conflicts - Regarding use of Alt-LMB, see #69323 (Remove/Update "Emulate Middle Mouse" preference) for possible conflicts. ### Open Topics - Some tools use the Alt key - such as shrink-fatten. ``` Possible solutions: ``` - Modal operators that use Alt will have to ignore the alt key on tool activation, then detect it on release and press. - The alt key behavior could be inverted when it's used for activation. - Requiring Alt-LMB to set the 3D cursor when tools are activated might not be preferred by some users. ``` Possible solutions: ``` - Keep the drag threshold for the tweak tool (perhaps all selection tools), so by default LMB-click places the cursor. - Have a preference to keep the current behavior - which uses a drag threshold to allow cursor placement and tools that drag. - Does this apply to other editors? time-line editors with tools (currently only the sequencer). Most likely placing the current frame with Alt-LMB isn't desirable, so we could opt-out of this in some cases (needs some further investigation).

Campbell Barton commented

2020-12-12 04:53:42 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Campbell Barton commented

2020-12-12 04:53:42 +01:00

Added subscriber: @ideasman42

Campbell Barton changed title from ~~Default Keymap Update to improve tool access (Use Alt-LMB for improved efficiency)~~ to Default Keymap Update: Improve tool access using Alt-LMB

2020-12-12 05:00:43 +01:00

Julien Kaspar commented

2020-12-14 15:56:02 +01:00

Added subscriber: @JulienKaspar

Julien Kaspar commented

2020-12-14 15:56:02 +01:00

Some tools use the Alt key - such as shrink-fatten.

This should be tested with more users. I could see it go with either solution but we need to be sure that it feels logical and consistent with how the rest of Blender works.

Requiring Alt-LMB to set the 3D cursor when tools are activated might not be preferred by some users.

We should decouple the task to add Alt + LMB drag to LCS & RCS and the task to remove left click for 3D/2D Cursor placement. One of them is just adding useful functionality (with the only conflict with 3 mouse button emulation) and the other might cause issues with some user workflows and needs to be further tested.
If it's ok to remove LC for setting the cursor from any tool other than the Cursor Tool then we can commit that too and remove all drag thresholds from the Tools in RCS.

Does this apply to other editors? time-line editors with tools (currently only the sequencer). Most likely placing the current frame with Alt-LMB isn't desirable, so we could opt-out of this in some cases (needs some further investigation).

Tools support for other editors such as node, animation, video editing should be a separate topic. Using Alt + LMB could be useful there too to solve some issue but this task should mainly be for the 3D Viewport & Image Editors since the behavior of 3D/2D cursors and tools is very similar there.
Adding Tool support for all Editors is going to be a huge task.

> Some tools use the Alt key - such as shrink-fatten. This should be tested with more users. I could see it go with either solution but we need to be sure that it feels logical and consistent with how the rest of Blender works. > Requiring Alt-LMB to set the 3D cursor when tools are activated might not be preferred by some users. We should decouple the task to add Alt + LMB drag to LCS & RCS and the task to remove left click for 3D/2D Cursor placement. One of them is just adding useful functionality (with the only conflict with 3 mouse button emulation) and the other might cause issues with some user workflows and needs to be further tested. If it's ok to remove LC for setting the cursor from any tool other than the Cursor Tool then we can commit that too and remove all drag thresholds from the Tools in RCS. > Does this apply to other editors? time-line editors with tools (currently only the sequencer). Most likely placing the current frame with Alt-LMB isn't desirable, so we could opt-out of this in some cases (needs some further investigation). Tools support for other editors such as node, animation, video editing should be a separate topic. Using Alt + LMB could be useful there too to solve some issue but this task should mainly be for the 3D Viewport & Image Editors since the behavior of 3D/2D cursors and tools is very similar there. Adding Tool support for all Editors is going to be a huge task.

Kurt Kellner commented

2021-01-21 01:31:53 +01:00

Added subscriber: @AlienTux

Paul Kotelevets commented

2021-05-09 14:29:07 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2021-05-09 14:29:07 +02:00

Well, yes, using gismos paradigm have several problems: it clutters viewport/selection, distorting visual shape of the model (which is also extremely distractive for models with tiny details), and require precise aiming motorics to use.
It is also unusable for editing long selections, like general plan roads or borders which have unpredictable and distant selection centers.

Usually, the ability to work without gizmos is the very first step to professional modeling, when you reach physical body speed limitations by avoiding using precise motoric actions every single time, and expands possible range of modeling workflows to architectural (interior/exterior) and precise engineering - with lots of numeric inputs in GZZ3.56 way during modeling process.

Previously gizmos in Blender was not that functional in comparison with other software and suddenly it played a positive role for general modeling in Blender.

Well, yes, using gismos paradigm have several problems: it clutters viewport/selection, distorting visual shape of the model (which is also extremely distractive for models with tiny details), and require precise aiming motorics to use. It is also unusable for editing long selections, like general plan roads or borders which have unpredictable and distant selection centers. Usually, the ability to work without gizmos is the very first step to professional modeling, when you reach physical body speed limitations by avoiding using precise motoric actions every single time, and expands possible range of modeling workflows to architectural (interior/exterior) and precise engineering - with lots of numeric inputs in GZZ3.56 way during modeling process. Previously gizmos in Blender was not that functional in comparison with other software and suddenly it played a positive role for general modeling in Blender.

Paul Kotelevets commented

2021-05-17 19:10:51 +02:00

... (we keep drag threshold as it's needed for detecting selection).

Delimiting action and selection with a threshold is quite questionable strategy.
Tests shown that it is impossible to define proper threshold value.
For example, a task of selecting several loops in a row (can be viewed from video here - https://developer.blender.org/T87910) can be performed by holding alt (alt+shift) and several LMB clicks.
If the threshold is low, there are a lot of false tools activations instead of loop selections, if the threshold is high - the activation of the instrument is too clumsy and unresponsive.

Human motor skills are always too much imperfect to handle input thresholds properly, it is always hard to control casual microdraggings.

> ... (we keep drag threshold as it's needed for detecting selection). Delimiting action and selection with a threshold is quite questionable strategy. Tests shown that it is impossible to define proper threshold value. For example, a task of selecting several loops in a row (can be viewed from video here - https://developer.blender.org/T87910) can be performed by holding alt (alt+shift) and several LMB clicks. If the threshold is low, there are a lot of false tools activations instead of loop selections, if the threshold is high - the activation of the instrument is too clumsy and unresponsive. Human motor skills are always too much imperfect to handle input thresholds properly, it is always hard to control casual microdraggings.

Chris Kohl commented

2021-06-18 20:56:45 +02:00

Added subscriber: @ckohl_art

Julien Kaspar commented

2021-07-17 15:42:00 +02:00

I've been testing the proposed addition of Alt + LMB to the LCS keymap and came to some more important conclusions:

1. Drag threshold needs to be smoothed

There are 2 ways the drag threshold behaves in Blender.

You click & drag a Gizmo. After the pixel threshold is reached the operation starts from the current cursor position.
You click & drag anywhere. After the pixel threshold is reached the operation starts from the original cursor position.

The first one leads to a more satisfying feel and allows more precise small tweaking.
The second one leads to sudden jumping which is barely noticeable on a low px threshold but very jarring with a pen or when doing very small fine tweaking (adjusting vertex position / Nudging keyframes 1-2 frames).
For an optimal experience we should make the first method the default for most drag thresholds that are in place, if not all of them.

2. Modifier keys need to be remembered when the click & drag starts

Here's a task for this issue: #89989
If you hold down a modifier key and click & drag, but let go of the modifier key before the drag threshold is reached, it will not use the modifier key for the operation.
As an example: You can hold Shift and drag an axis of the transform gizmo to transform along a plane instead of an axis.
Typically this happens so fast with a mouse that users would let go of Shift immediately after clicking (which is also more comfortable instead of keeping it held).
But doing that with a pen (a high px drag threshold) will often lead to nothing happening at all.

Blender generally encourages holding modifier keys before and during a click and then letting go of that modifier key.
If a modifier key is let go it won't change the operation that already started.
So to make this work even better (Especially if Alt + LMB drag is used many times each minute) Blender needs to only take only take into account the modifier keys that are pressed when the click & drag occurs, and remember them if the operation is executed after the drag threshold is reached.
Any modifier key that is held in between the click & drag and reaching the drag threshold should be used as a modifier key to change the settings of the upcoming operation, which leads me to:

3. Modifier keys before and after start of any operation should be good as it is

Some tools use the Alt key - such as shrink-fatten

In my previous example of holding Shift to start a different operation on the transform gizmo there seems to also be a conflict with holding Shift while transforming to move elements more precisely.
But in my experience this didn't really occur.
Generally you end up holding Shift while dragging on the Gizmo but letting go immediately after. Then you hold Shift again if you want to move things precisely.
If the behaviour ends up like I mentioned in the previous point then there should be no issue.

4. Editors without broad or any active tool support do not need this addition to the keymap

Does this apply to other editors? time-line editors with tools (currently only the sequencer). Most likely placing the current frame with Alt-LMB isn't desirable, so we could opt-out of this in some cases (needs some further investigation).

The behaviour in other editors than the 3D viewport and UV editor is generally to have a versatile default tool that can box select and tweak selected elements.
Since this can easily be the primary way of interacting with the active tools in those editors there is not need for anything more complex.
Alt + LMB drag also already has some functionality in some of these editors so it's best not reshuffle the keymap.

5. Gizmos should change based on the modifier keys that are held

Based on if the Drag setting in a tool is set to "Active Tools" or any of the other selection methods, the Gizmo may be visible or not.
Ideally while modifier key cause the same behaviour. So if Alt is held the Gizmo of the currently active Tool will disappear.
A possible better solution that communicates the behaviour better is to show change the cursor appearance too.

I've been testing the proposed addition of Alt + LMB to the LCS keymap and came to some more important conclusions: **1. Drag threshold needs to be smoothed** There are 2 ways the drag threshold behaves in Blender. - You click & drag a Gizmo. After the pixel threshold is reached the operation starts from the **current** cursor position. - You click & drag anywhere. After the pixel threshold is reached the operation starts from the **original** cursor position. The first one leads to a more satisfying feel and allows more precise small tweaking. The second one leads to sudden jumping which is barely noticeable on a low px threshold but very jarring with a pen or when doing very small fine tweaking (adjusting vertex position / Nudging keyframes 1-2 frames). For an optimal experience we should make the first method the default for most drag thresholds that are in place, if not all of them. **2. Modifier keys need to be remembered when the click & drag starts** Here's a task for this issue: #89989 If you hold down a modifier key and click & drag, but let go of the modifier key before the drag threshold is reached, it will not use the modifier key for the operation. As an example: You can hold Shift and drag an axis of the transform gizmo to transform along a plane instead of an axis. Typically this happens so fast with a mouse that users would let go of Shift immediately after clicking (which is also more comfortable instead of keeping it held). But doing that with a pen (a high px drag threshold) will often lead to nothing happening at all. Blender generally encourages holding modifier keys before and during a click and then letting go of that modifier key. If a modifier key is let go it won't change the operation that already started. So to make this work even better (Especially if Alt + LMB drag is used many times each minute) Blender needs to only take only take into account the modifier keys that are pressed when the click & drag occurs, and remember them if the operation is executed after the drag threshold is reached. Any modifier key that is held in between the click & drag and reaching the drag threshold should be used as a modifier key to change the settings of the upcoming operation, which leads me to: **3. Modifier keys before and after start of any operation should be good as it is** > Some tools use the Alt key - such as shrink-fatten In my previous example of holding Shift to start a different operation on the transform gizmo there seems to also be a conflict with holding Shift while transforming to move elements more precisely. But in my experience this didn't really occur. Generally you end up holding Shift while dragging on the Gizmo but letting go immediately after. Then you hold Shift again if you want to move things precisely. If the behaviour ends up like I mentioned in the previous point then there should be no issue. **4. Editors without broad or any active tool support do not need this addition to the keymap** > Does this apply to other editors? time-line editors with tools (currently only the sequencer). Most likely placing the current frame with Alt-LMB isn't desirable, so we could opt-out of this in some cases (needs some further investigation). The behaviour in other editors than the 3D viewport and UV editor is generally to have a versatile default tool that can box select and tweak selected elements. Since this can easily be the primary way of interacting with the active tools in those editors there is not need for anything more complex. Alt + LMB drag also already has some functionality in some of these editors so it's best not reshuffle the keymap. **5. Gizmos should change based on the modifier keys that are held** Based on if the Drag setting in a tool is set to "Active Tools" or any of the other selection methods, the Gizmo may be visible or not. Ideally while modifier key cause the same behaviour. So if Alt is held the Gizmo of the currently active Tool will disappear. A possible better solution that communicates the behaviour better is to show change the cursor appearance too.

Julien Kaspar commented

2022-05-12 23:32:02 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Julien Kaspar closed this issue

2022-05-12 23:32:02 +02:00

Julien Kaspar self-assigned this 2022-05-12 23:32:02 +02:00

Julien Kaspar commented

2022-05-12 23:32:02 +02:00

All these proposals are now implemented so I'll close this task.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Default Keymap Update: Improve tool access using Alt-LMB #83689

Conflicts

Open Topics