Page MenuHome

Shortcuts for Tools (design task)
Open, NormalPublic

Description

One of the major issues with the tool system, is that switching tools isn't easy enough using the keyboard with the default keymap.

We would like to introduce a way to make the keyboard shortcuts switch tools, without having to click on the toolbar, or opening menus. Here's how we think we can solve it:

We want to leverage muscle memory for shortcuts users already know, such as G, R, S for the transform tools, as well as K for Knife, Alt-S for Move Along Normals, and so on.

Leader Keys

To do this, we use the concept of leader keys (also known as chained keys). This makes it so that tapping (but not holding) a modifier will change the following shortcut. In this case we think we will use Alt to switch tools.

In practice, this means users will tap Alt, then G to switch to the Move tool, and so forth.

Visual Feedback

We want to make it obvious that a leader key has been entered, so that users know that the following key stroke will differ from normal. We do this in a few ways:

Status Bar

Here we can see the leader key, plus the shortcuts:

Toolbar

After the leader key is pressed, we can also display the hotkeys inside the toolbar buttons. This gives a more direct association with the tools in the toolbar and their corresponding shortcut.

Implementation

  • Pressing Alt and releasing (without pressing another key) would prompt for input.
    • Pressing any of the mapped keys would activate the tool immediately.
    • Pressing any key not mapped - such as painting or using mouse buttons to pan the view - would cancel the prompt and perform the action (preventing unintended leader key press from Blocking other actions). Pressing escape would also cancel.

Precedents

  • Firefox supports accessing menu this way (Tapping Alt, then F opens the file menu).
  • Typing in accent characters on macOS uses leader-key like functionality.
  • Spacemacs relies heavily on a leader key.

Details

Type
Design

Event Timeline

William Reynish (billreynish) lowered the priority of this task from Needs Triage by Developer to Normal.
William Reynish (billreynish) changed Type from Bug to Design.

Is the end goal a true vim-style leader key system, or a version of the wm.toolbar operator that uses UI overlays instead of a popover?

I'm sure you have thought of this, but as described there might be some issues caused by toolbars being per-editor, while the status bar is global. And other related problems caused by the leader key being a press rather than a hold.

Since we are talking about using the tap of a key rather than holding it as a modifier, how long do you wait for the next key? Since the leader key press is transitory, not a hold, when does the following state happen exactly? Is this shown immediately after pressing of Alt or on release? If on release how long does it wait? What if you move your mouse to a different editor? What if you press something else?

If I just press Alt does it wait forever and seem broken if I don't hit one of the allowed keys? Does it time out? Or do I have to hit Esc to exit the mode? If I hit some other key, like "E", does it cause an error message, ignored, or cancel the mode?

Campbell Barton (campbellbarton) updated the task description. (Show Details)

@Harley Acheson (harley) edited the task to include exact behavior, see "Implementation"

@Campbell Barton (campbellbarton) - yes, thanks! Wasn't trying to shit on it, just trying to think it through.

Hmmm, although... seeing that "Alt", "G", "R", and "S" makes me think it might be nice to have outline and background color added to uiFontStyle. Might be a better way of doing that than the event icons since those have to be fixed width.

Don't all tools have hotkeys already? How would addons be affected?
Maybe an Alt/T menu is needed for people who map the spacebar to other than Tools?
Currently it's easy to press spacebar for the menu, then use the hotkeys after for speed/non mouse move.
Is all this dressing really needed? Isn't there enough ui confusion to look at before adding more?
Maybe I'm misunderstanding things here.

While it's definitely important to be able to easily access tools i'm not sure about that solution. I don't see why it's necessary to have a whole new UI concept only to be able to do 2 things that are ment to do the same task:

  1. trigger a modal operator
  2. activating a tool with its gizmos

I'd prefer tools to be directly activated (like in: D4603) and let them behave slightly different when activated by a shortcut. That would mean something like the following:

-where a tool is available pressing the shortcut switches to the appropriate tool rather than the modal operator

for tools that need a selection to work:
-switching to a tool by shortcut should invoke the tweaking of their primary property when there's already a valid selection (similar to modal operators)

-switching to a tool if there's no valid selection, would only activate it without any action

-switching to the already active tool could apply the modification and trigger the action again

Pros:
-Tools somewhat mimik the operators workflow wich has been proven to be fast and efficient
-Advanced users can still work shortcut based but also make use of gizmos
-Beginners can easily adapt a fast workflow once they are familiar with a tool and discover the shortcut, because there's no difference between tool/operator

Cons:
-Shortcuts to activate tools could conflict with tool keymaps -> tool keymaps should probably be limited to a given set of keys
-the UI might end up flashing alot more when the tool changes every time one would execute a modal operator -> gizmos / toolbar / topbar can all be hidden, not sure how big of a problem that is

I like the idea of leader keys as a general feature, and I could see using T or Spacebar as a leader for tool-switching (toggling toolbar visibility or calling a different operator with TT or Dbl-Spacebar), but I don't think Alt is a good default. Programs that use Alt as a leader, or to initialize a keyboard-based UI navigation mode, tend to use input schemas that aren't directly comparable to Blender's, using either fewer modifier keys in general or a firmer division between mouse-based and keyboard-based input modes. I'd investigate other options, including off-the-wall ones like Tab as a leader or Enter to toggle shortcuts between modals and tools, before getting too far into this.

@Brendon Murphy (meta-androcto), while space-bar tool menu works it's not default.


@David Friedli (hlorus)

I don't see why it's necessary to have a whole new UI concept only to be able to do 2 things that are ment to do the same task:

  1. trigger a modal operator
  2. activating a tool with its gizmos

Whether this is a new UI concept or not is fuzzy, it's a new way of accessing tools but don't think it's so different to other modal states in Blender.

making keys activate tools immediately is too disruptive to existing Blender users and will slow down their workflow. Otherwise, the changes you suggest are fairly larger and would better be posted to T66304: Tools, Selection & Gizmo design.


@Asher (ThatAsherGuy)

The exact key can be changed, Alt is convenient because it's easily accessible - similar to other modifiers. Even people who don't touch type can press it without looking at the keyboard.

Having said that, we're not locked into using this key, once implemented we could have different leader keys or user defined leaders keys that perform different actions.

@Campbell Barton (campbellbarton)

Thanks for the response, i commented on the task you mentioned.