Shortcuts for Tools (design task) #69992

New Issue

William Reynish · 2019-09-17T20:17:58+02:00

William Reynish commented

2019-09-17 20:17:58 +02:00

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:
{F7753731, size=full}

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.
{F7753735, size=full}

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 .

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: {[F7753731](https://archive.blender.org/developer/F7753731/Screenshot_2019-09-15_at_21.50.34.png), size=full} **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. {[F7753735](https://archive.blender.org/developer/F7753735/Screenshot_2019-09-15_at_21.43.58.png), size=full} ## 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. ](https://www.idownloadblog.com/2019/01/03/type-accents-on-mac-keyboard/) - Spacemacs relies heavily on a [leader key ](http://spacemacs.org/doc/QUICK_START.html#the-leader-keys).

William Reynish commented

2019-09-17 20:17:58 +02:00

Added subscriber: @WilliamReynish

Campbell Barton was assigned by William Reynish

2019-09-17 20:18:13 +02:00

William Reynish commented

2019-09-17 20:18:29 +02:00

No description provided.

Julien Kaspar commented

2019-09-17 20:31:03 +02:00

Added subscriber: @JulienKaspar

Asher commented

2019-09-18 01:02:08 +02:00

Added subscriber: @ThatAsherGuy

Asher commented

2019-09-18 01:02:08 +02:00

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?

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?

Harley Acheson commented

2019-09-18 02:28:41 +02:00

Added subscriber: @Harley

Harley Acheson commented

2019-09-18 02:28:41 +02:00

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?

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? ![status.png](https://archive.blender.org/developer/F7754275/status.png) 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 commented

2019-09-18 02:39:28 +02:00

@Harley edited the task to include exact behavior, see "Implementation"

Harley Acheson commented

2019-09-18 02:44:38 +02:00

@ideasman42 - yes, thanks! Wasn't trying to shit on it, just trying to think it through.

Harley Acheson commented

2019-09-18 03:03:06 +02:00

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.

David Friedli commented

2019-09-18 08:58:54 +02:00

Added subscriber: @hlorus

Brendon Murphy commented

2019-09-18 09:01:54 +02:00

Added subscriber: @BrendonMurphy

Brendon Murphy commented

2019-09-18 09:01:54 +02:00

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.

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.

David Friedli commented

2019-09-18 13:50:57 +02:00

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:

trigger a modal operator
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

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](https://archive.blender.org/developer/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

Asher commented

2019-09-19 17:26:28 +02:00

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.

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.

renderhjs commented

2019-09-28 03:28:57 +02:00

Added subscriber: @renderhjs

Campbell Barton commented

2019-10-02 15:03:06 +02:00

@BrendonMurphy, while space-bar tool menu works it's not default.

@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:

trigger a modal operator

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 #66304 (Tools, Selection & Gizmo design).

@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.

@BrendonMurphy, while space-bar tool menu works it's not default. ---- @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: > > # trigger a modal operator > # 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 #66304 (Tools, Selection & Gizmo design). ---- @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.

David Friedli commented

2019-10-06 19:38:40 +02:00

@ideasman42

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

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

MACHIN3 commented

2019-10-28 14:06:39 +01:00

Added subscriber: @MACHIN3

ronan ducluzeau commented

2019-10-28 17:30:19 +01:00

Added subscriber: @zeauro

ronan ducluzeau commented

2019-10-28 17:30:19 +01:00

Currently, cursor tool is not accessible that way.
C is used for Circle Select.
Toolbar popup uses Spacebar. But Alt tapping does not.
Don't you think it could be a good default to have a solution for this active tool ?

IMO, active tool is superior than shift right click shortcut. Because it supports snapping and rotation options for 3D Cursor in a more intuitive way.

Currently, cursor tool is not accessible that way. C is used for Circle Select. Toolbar popup uses Spacebar. But Alt tapping does not. Don't you think it could be a good default to have a solution for this active tool ? IMO, active tool is superior than shift right click shortcut. Because it supports snapping and rotation options for 3D Cursor in a more intuitive way.

Andres Stephens commented

2019-10-28 17:41:07 +01:00

Added subscriber: @AndresStephens

Andres Stephens commented

2019-10-28 17:41:07 +01:00

Adding another layer of hotkeys is not a user friendly solution. Writing with accent hotkeys, eg, is very slowing and tiring.

The alternative is to.. improve the keymap editor and unification of identical operators. eg. Transform with legacy transform should be the one and the same tool and hotkey, not two.

Adding another layer of hotkeys is not a user friendly solution. Writing with accent hotkeys, eg, is very slowing and tiring. The alternative is to.. improve the keymap editor and unification of identical operators. eg. Transform with legacy transform should be the one and the same tool and hotkey, not two.

Alberto Velázquez commented

2019-10-28 19:26:58 +01:00

Added subscriber: @AlbertoVelazquez

Alberto Velázquez commented

2019-10-28 19:26:58 +01:00

It won't work well with paint vertex, sculpt, Uvs,... Also It have few sense, if the user wants active tools he don't need modal shortcuts. If the user uses modal shortcuts he won't need active tools. Also if the user is advanced he will know to change the shortcut of a active tool.

Is more easy made the old proposal

Allow user switch all hotkeys of modal tools and active tools when blender begin first time
allow user go back to select mode pressing ESC
Allow user to have passive tools like move, rotate and scale with select.

less clicks and key pressed, problem solved.

It won't work well with paint vertex, sculpt, Uvs,... Also It have few sense, if the user wants active tools he don't need modal shortcuts. If the user uses modal shortcuts he won't need active tools. Also if the user is advanced he will know to change the shortcut of a active tool. Is more easy made the old proposal - Allow user switch all hotkeys of modal tools and active tools when blender begin first time - allow user go back to select mode pressing ESC - Allow user to have passive tools like move, rotate and scale with select. less clicks and key pressed, problem solved.

Campbell Barton commented

2019-10-28 19:46:42 +01:00

In #69992#802160, @zeauro wrote:
Currently, cursor tool is not accessible that way.
C is used for Circle Select.
Toolbar popup uses Spacebar. But Alt tapping does not.
Don't you think it could be a good default to have a solution for this active tool ?

Alt, Space now activates the 3D cursor 1ed46bf727

> In #69992#802160, @zeauro wrote: > Currently, cursor tool is not accessible that way. > C is used for Circle Select. > Toolbar popup uses Spacebar. But Alt tapping does not. > Don't you think it could be a good default to have a solution for this active tool ? Alt, Space now activates the 3D cursor 1ed46bf727

Alessio Monti di Sopra commented

2019-10-28 19:51:17 +01:00

Added subscriber: @a.monti

Alessio Monti di Sopra commented

2019-10-28 19:51:17 +01:00

I don't think I understand the reasons behind this proposal to be honest.

Right now we can do the same thing with Shift+Spacebar but that implementation is better imo since, apart from allowing you to press the tool key, you can also simply hover the cursor over it, it's also more visually evident and it's dismissible by moving the mouse away.

I don't think I understand the reasons behind this proposal to be honest. Right now we can do the same thing with **Shift+Spacebar** but that implementation is better imo since, apart from allowing you to press the tool key, you can also simply hover the cursor over it, it's also more visually evident and it's dismissible by moving the mouse away.

Campbell Barton commented

2019-10-28 19:52:26 +01:00

In #69992#802246, @AlbertoVelazquez wrote:
It won't work well with paint vertex, sculpt, Uvs,...

Those modes don't especially need this. This doesn't mean it doesn't work well, just that it's not needed in these modes.

Also It have few sense, if the user wants active tools he don't need modal shortcuts.

That doesn't mean they don't want to use shortcuts to change tools.

If the user uses modal shortcuts he won't need active tools.

Some tools aren't accessible directly, Measure or Transform gizmo for example.

Also if the user is advanced he will know to change the shortcut of a active tool.

Expecting any users (advanced or not) to map tools to their own key bindings isn't reasonable. They might map one or two, but mapping many becomes a hassle to maintain.

> In #69992#802246, @AlbertoVelazquez wrote: > It won't work well with paint vertex, sculpt, Uvs,... Those modes don't especially need this. This doesn't mean it doesn't work well, just that it's not needed in these modes. > Also It have few sense, if the user wants active tools he don't need modal shortcuts. That doesn't mean they don't want to use shortcuts to change tools. > If the user uses modal shortcuts he won't need active tools. Some tools aren't accessible directly, Measure or Transform gizmo for example. > Also if the user is advanced he will know to change the shortcut of a active tool. Expecting any users (advanced or not) to map tools to their own key bindings isn't reasonable. They might map one or two, but mapping many becomes a hassle to maintain.

Alberto Velázquez commented

2019-10-28 21:51:45 +01:00

In #69992#802283, @ideasman42 wrote:
Those modes don't especially need this. This doesn't mean it doesn't work well, just that it's not needed in these modes.

It is not a good solution have different shortcuts for same paradigms depending of the mode. It's make more complex the software when you could have easy solutions, like have another option in the splash screen. Also that use alt like that modifier is prone to errors.

That doesn't mean they don't want to use shortcuts to change tools.

But only shortcuts for active tools, that overwrite modal tools shortcuts.

Some tools aren't accessible directly, Measure or Transform gizmo for example.

Well, like are not modal tools that shortcuts can be shared by modal and active tool keymaps.

Expecting any users (advanced or not) to map tools to their own key bindings isn't reasonable. They might map one or two, but mapping many becomes a hassle to maintain.

That's not true, an advanced user change a lot of shortcuts. More when in blender2.8 you have change a lot of shortcuts.

Seriously, after having erased the T-shelf and then bring it back to the sidebar. To create the popup to select active tools and then leave forgotten. To put the active tools in the panel of properties..... This seems like another new step of how to delve into the problem of a bad design of the use of the active tools instead of search a simple solution.

> In #69992#802283, @ideasman42 wrote: > Those modes don't especially need this. This doesn't mean it doesn't work well, just that it's not needed in these modes. It is not a good solution have different shortcuts for same paradigms depending of the mode. It's make more complex the software when you could have easy solutions, like have another option in the splash screen. Also that use alt like that modifier is prone to errors. > That doesn't mean they don't want to use shortcuts to change tools. But only shortcuts for active tools, that overwrite modal tools shortcuts. > Some tools aren't accessible directly, Measure or Transform gizmo for example. Well, like are not modal tools that shortcuts can be shared by modal and active tool keymaps. > Expecting any users (advanced or not) to map tools to their own key bindings isn't reasonable. They might map one or two, but mapping many becomes a hassle to maintain. That's not true, an advanced user change a lot of shortcuts. More when in blender2.8 you have change a lot of shortcuts. Seriously, after having erased the T-shelf and then bring it back to the sidebar. To create the popup to select active tools and then leave forgotten. To put the active tools in the panel of properties..... This seems like another new step of how to delve into the problem of a bad design of the use of the active tools instead of search a simple solution.

MACHIN3 commented

2019-10-28 22:02:03 +01:00

As a vim user, I applaud the introduction of leader keys. I hope it will be integrated in a general way that's applicable to every kind of shortcut. I already use the underlined letter shortcuts in (pie) menus to start chaining key presses, and then often continue them in various modal operaters I've made.

It's a great concept. Looking forward to where this goes. Using a leader key to switch tools is a great start IMO.

As a vim user, I applaud the introduction of leader keys. I hope it will be integrated in a general way that's applicable to every kind of shortcut. I already use the *underlined letter shortcuts* in (pie) menus to start chaining key presses, and then often continue them in various modal operaters I've made. It's a great concept. Looking forward to where this goes. Using a leader key to switch tools is a great start IMO.

mankysee commented

2019-10-28 23:19:14 +01:00

Added subscriber: @mankysee

mankysee commented

2019-10-28 23:19:14 +01:00

Speaking from my own perspective the first thing i've done with the final blender 2.80 was changing the hotkeys for grab/rotate/scale from operators to tools(because I like to get a visual feedback when moving along the axis and I've always been using gizmos where they were available).

I've done this mostly because it's confusing to have two tools doing the same thing but doing that thing a little differently. For example a loop cut tool don't have the same functionality as a loop cut operator assigned to ctrl-r(you can't add more loops using mouse wheel if you click on a tool in a shelf but you can do this if you invoke an operator via shortcut; this makes the tool almost useless for anything other than a basic use btw). That's less obvious with grab/rotate/scale operators and you can have kinda old behaviour if you click and drag outside the gizmos but the inconvenience is still there(kinda-like since for example pressing x/y/z for isolating axis won't work with g/r/s tools).

With adding more shortcuts instead of unifying behaviour across the board between tools and similar operators it will be an even more confusing for new users(I've been always have to explain why default shortcuts for grab/rotate/scale are behaving differently then a same named tool when explaining blender to new users and that was happening more that a few times).

Therefore I think this is a bad idea both for power users who can find their way to change shortcuts by themselves(actually it's not that hard for new users too, it's just one click on a tool) and for new users alike since it brings even more shortcuts for seemingly same things but somehow working differently. The best solution to the problem this proposal is trying to solve would be not to bring more shortcuts on top of other shortcuts but a unified tool/shortcut-operator behaviour with an optional but visible toggle that would show/hide gizmos for all tools/operators used until it's unchecked(more or less like it was in 2.79). So if the toggle is on pressing g would invoke a grab operator(with all the options like pressing x to lock x axis etc) with gizmo and with no immediate dragging applied while the toggle is of the same grab operator would be invoked with a "classic" blender behaviour and so on.

Speaking from my own perspective the first thing i've done with the final blender 2.80 was changing the hotkeys for grab/rotate/scale from operators to tools(because I like to get a visual feedback when moving along the axis and I've always been using gizmos where they were available). I've done this mostly because it's confusing to have two tools doing the same thing but doing that thing a little differently. For example a loop cut tool don't have the same functionality as a loop cut operator assigned to ctrl-r(you can't add more loops using mouse wheel if you click on a tool in a shelf but you can do this if you invoke an operator via shortcut; this makes the tool almost useless for anything other than a basic use btw). That's less obvious with grab/rotate/scale operators and you can have kinda old behaviour if you click and drag outside the gizmos but the inconvenience is still there(kinda-like since for example pressing x/y/z for isolating axis won't work with g/r/s tools). With adding more shortcuts instead of unifying behaviour across the board between tools and similar operators it will be an even more confusing for new users(I've been always have to explain why default shortcuts for grab/rotate/scale are behaving differently then a same named tool when explaining blender to new users and that was happening more that a few times). Therefore I think this is a bad idea both for power users who can find their way to change shortcuts by themselves(actually it's not that hard for new users too, it's just one click on a tool) and for new users alike since it brings even more shortcuts for seemingly same things but somehow working differently. The best solution to the problem this proposal is trying to solve would be not to bring more shortcuts on top of other shortcuts but a unified tool/shortcut-operator behaviour with an optional but visible toggle that would show/hide gizmos for all tools/operators used until it's unchecked(more or less like it was in 2.79). So if the toggle is on pressing g would invoke a grab operator(with all the options like pressing x to lock x axis etc) with gizmo and with no immediate dragging applied while the toggle is of the same grab operator would be invoked with a "classic" blender behaviour and so on.

ronan ducluzeau commented

2019-10-29 11:53:14 +01:00

I prefer this Alt tapping that does not introduce visual disturbance like shift space toolbar popover that requires to use two fingers.

But I agree that is a similar solution. Although power user can assign shortcuts, he will not create and retain hundreds of them and will use toolbar one way or the other.
I recently tried to teach 2.80 to newbies. And I have to restrain myself to show them only one way to do a thing, otherwise, I will lost them and not be able to make them learn basics in a reasonable of time.

That is a situation a little bit similar to texture paint mode where brush sliders are available in 4 different places.
That is not a bad thing to give several options to user. But it is prejudice to avoid to make choices for official release.

Not all active tools are directly accessible in toolbar and toolbar popover that requires to make a press click on button of active tool of same category.
With this leader key, all active tools shortcuts in object mode are visible in status bar. But it is no more the case in edit mode, they are too numerous.

I think that idea is good. But I think that should be restrained to some tools and not all; like tool settings bar in texture paint mode should be restrained to some settings of brush and not all.
We need a system to let user customize UI to tell : "For this tool, I use this solution. For that tool, I use another one." And we need same kind of choices done in official release.

Seriously, I will continue to use tilde pie-menu to set a transform gizmo because that allows me to use a select tool or 3D cursor as active tool at same time.
Really, Move, Rotate & Scale active tools are less efficient choice that a user can make.
Use of their gizmo does not allow to select with left click at same time and they can not be combine like when using Transform active tool.
But those active tools with great icons in evident toolbar are the most discoverable way to do things.
It is difficult to say to your student : "this obvious thing that is easy to retain : don't use it. It is slowing you down and limiting you. Use the thing difficult to remember (because it is hidden) or the one with more buttons to click on or force yourself to remember 3 shortcuts and middle mouse axis constraint."

To allow combination of several gizmos, Toolbar should allow to activate several tools at same time. That would be the most simplest way to have an obvious and efficient solution.
Toolbar should display directly all tools unless user creates categories to arrange them.
This alt tapping should be reserve to most common active tools unless user configures the feature in another way.

To sum-up, I think that customization should be added for that feature. Why not adding or removing an active tool by a right click menu ? Like a quick favorites menu for active tools.

I prefer this Alt tapping that does not introduce visual disturbance like shift space toolbar popover that requires to use two fingers. But I agree that is a similar solution. Although power user can assign shortcuts, he will not create and retain hundreds of them and will use toolbar one way or the other. I recently tried to teach 2.80 to newbies. And I have to restrain myself to show them only one way to do a thing, otherwise, I will lost them and not be able to make them learn basics in a reasonable of time. That is a situation a little bit similar to texture paint mode where brush sliders are available in 4 different places. That is not a bad thing to give several options to user. But it is prejudice to avoid to make choices for official release. Not all active tools are directly accessible in toolbar and toolbar popover that requires to make a press click on button of active tool of same category. With this leader key, all active tools shortcuts in object mode are visible in status bar. But it is no more the case in edit mode, they are too numerous. I think that idea is good. But I think that should be restrained to some tools and not all; like tool settings bar in texture paint mode should be restrained to some settings of brush and not all. We need a system to let user customize UI to tell : "For this tool, I use this solution. For that tool, I use another one." And we need same kind of choices done in official release. Seriously, I will continue to use tilde pie-menu to set a transform gizmo because that allows me to use a select tool or 3D cursor as active tool at same time. Really, Move, Rotate & Scale active tools are less efficient choice that a user can make. Use of their gizmo does not allow to select with left click at same time and they can not be combine like when using Transform active tool. But those active tools with great icons in evident toolbar are the most discoverable way to do things. It is difficult to say to your student : "this obvious thing that is easy to retain : don't use it. It is slowing you down and limiting you. Use the thing difficult to remember (because it is hidden) or the one with more buttons to click on or force yourself to remember 3 shortcuts and middle mouse axis constraint." To allow combination of several gizmos, Toolbar should allow to activate several tools at same time. That would be the most simplest way to have an obvious and efficient solution. Toolbar should display directly all tools unless user creates categories to arrange them. This alt tapping should be reserve to most common active tools unless user configures the feature in another way. To sum-up, I think that customization should be added for that feature. Why not adding or removing an active tool by a right click menu ? Like a quick favorites menu for active tools.

Campbell Barton commented

2019-10-29 15:44:30 +01:00

In #69992#802342, @MACHIN3 wrote:
As a vim user, I applaud the introduction of leader keys. I hope it will be integrated in a general way that's applicable to every kind of shortcut. I already use the underlined letter shortcuts in (pie) menus to start chaining key presses, and then often continue them in various modal operaters I've made.

It's a great concept. Looking forward to where this goes. Using a leader key to switch tools is a great start IMO.

Having generic leader keys is fairly trivial to implement now, it's mostly a matter of connecting different parts of the API.

I would have liked if switching tools could use a generic system however there are some details that made it impractical.

> In #69992#802342, @MACHIN3 wrote: > As a vim user, I applaud the introduction of leader keys. I hope it will be integrated in a general way that's applicable to every kind of shortcut. I already use the *underlined letter shortcuts* in (pie) menus to start chaining key presses, and then often continue them in various modal operaters I've made. > > It's a great concept. Looking forward to where this goes. Using a leader key to switch tools is a great start IMO. Having generic leader keys is fairly trivial to implement now, it's mostly a matter of connecting different parts of the API. I would have liked if switching tools could use a generic system however there are some details that made it impractical.

Campbell Barton commented

2019-10-29 15:55:30 +01:00

In #69992#802282, @a.monti wrote:
I don't think I understand the reasons behind this proposal to be honest.

Right now we can do the same thing with Shift+Spacebar but that implementation is better imo since, apart from allowing you to press the tool key, you can also simply hover the cursor over it, it's also more visually evident and it's dismissible by moving the mouse away.

I can see you're point, personally I didn't mind using this, however artists I talked to (Julian at the Blender Institute for eg, others too IIRC) didn't view this as a short-cut even though it allows shortcut style access.

Some statements to the effect: "If it's a shortcut why is it flashing a menu?

In #69992#802607, @zeauro wrote:
I prefer this Alt tapping that does not introduce visual disturbance like shift space toolbar popover that requires to use two fingers.

When I added this it used one finger (Spacebar), however this didn't end up being a popular choice - from what I can tell.

As you say, this has less visual disturbance.

In #69992#802607, @zeauro wrote:
Not all active tools are directly accessible in toolbar and toolbar popover that requires to make a press click on button of active tool of same category.
With this leader key, all active tools shortcuts in object mode are visible in status bar. But it is no more the case in edit mode, they are too numerous.

Currently not all tools are accessible (additional annotation tools for eg aren't although all could be exposed).

The issue wit having too many items in edit-mode should be addressed too. Perhaps names could be abbreviated.

> In #69992#802282, @a.monti wrote: > I don't think I understand the reasons behind this proposal to be honest. > > Right now we can do the same thing with **Shift+Spacebar** but that implementation is better imo since, apart from allowing you to press the tool key, you can also simply hover the cursor over it, it's also more visually evident and it's dismissible by moving the mouse away. I can see you're point, personally I didn't mind using this, however artists I talked to (Julian at the Blender Institute for eg, others too IIRC) didn't view this as a short-cut even though it allows shortcut style access. Some statements to the effect: *"If it's a shortcut why is it flashing a menu?* ---- > In #69992#802607, @zeauro wrote: > I prefer this Alt tapping that does not introduce visual disturbance like shift space toolbar popover that requires to use two fingers. When I added this it used one finger (Spacebar), however this didn't end up being a popular choice - from what I can tell. As you say, this has less visual disturbance. ---- > In #69992#802607, @zeauro wrote: > Not all active tools are directly accessible in toolbar and toolbar popover that requires to make a press click on button of active tool of same category. > With this leader key, all active tools shortcuts in object mode are visible in status bar. But it is no more the case in edit mode, they are too numerous. Currently not all tools are accessible (additional annotation tools for eg aren't although all could be exposed). The issue wit having too many items in edit-mode should be addressed too. Perhaps names could be abbreviated.

Mindinsomnia commented

2019-10-30 00:26:23 +01:00

Added subscriber: @Grady

Mindinsomnia commented

2019-10-30 00:26:23 +01:00

Interesting proposal, but I think it would pretty significantly slow down workflow for modelling. Going from being able to grab, rotate and scale with one tap of a key, to requiring two taps of two keys, will mean basically double the number of keystrokes. It also seems out of step with how other similar professional tools work. I understand the example of Firefox uses this system, but other design applications such as Photoshop, GIMP, Inkscape, Krita, etc, don't use that kind of behaviour.

At the very least I think your point about displaying the keymap for a button on the button itself in the UI for the toolbar, should be integrated, otherwise the user really has to go hunting to figure out what the keymap is for something. The keymap for a button could be displayed while the button is expanded and in it's large form, displaying both icon and label. It could also be mentioned in the hover tip for all of the toolbar buttons, so the user can discover the keymap while the buttons are condensed to only display icons. That's something which seems to be kinda inconsistent at the moment with Blender, some UI elements display the keymapping with a hovertext while others don't.

Interesting proposal, but I think it would pretty significantly slow down workflow for modelling. Going from being able to grab, rotate and scale with one tap of a key, to requiring two taps of two keys, will mean basically double the number of keystrokes. It also seems out of step with how other similar professional tools work. I understand the example of Firefox uses this system, but other design applications such as Photoshop, GIMP, Inkscape, Krita, etc, don't use that kind of behaviour. At the very least I think your point about displaying the keymap for a button on the button itself in the UI for the toolbar, should be integrated, otherwise the user really has to go hunting to figure out what the keymap is for something. The keymap for a button could be displayed while the button is expanded and in it's large form, displaying both icon and label. It could also be mentioned in the hover tip for all of the toolbar buttons, so the user can discover the keymap while the buttons are condensed to only display icons. That's something which seems to be kinda inconsistent at the moment with Blender, some UI elements display the keymapping with a hovertext while others don't.

Campbell Barton commented

2019-10-30 00:34:31 +01:00

In #69992#803074, @Grady wrote:
Interesting proposal, but I think it would pretty significantly slow down workflow for modelling. Going from being able to grab, rotate and scale with one tap of a key, to requiring two taps of two keys, will mean basically double the number of keystrokes.

Single key access to directly run operators has not been removed.

At the very least I think your point about displaying the keymap for a button on the button itself in the UI for the toolbar, should be integrated, otherwise the user really has to go hunting to figure out what the keymap is for something.

This is in this proposal and still planned.

> In #69992#803074, @Grady wrote: > Interesting proposal, but I think it would pretty significantly slow down workflow for modelling. Going from being able to grab, rotate and scale with one tap of a key, to requiring two taps of two keys, will mean basically double the number of keystrokes. Single key access to directly run operators has not been removed. > At the very least I think your point about displaying the keymap for a button on the button itself in the UI for the toolbar, should be integrated, otherwise the user really has to go hunting to figure out what the keymap is for something. This is in this proposal and still planned.

Viktor commented

2019-10-30 08:24:48 +01:00

Added subscriber: @Voronium

Viktor commented

2019-10-30 08:24:48 +01:00

As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it:

Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...)
Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state.

This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool.

As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it: 1) Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...) 2) Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state. This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool.

Andrei Nadin commented

2019-10-30 08:31:07 +01:00

Added subscriber: @AnadinX

Andrei Nadin commented

2019-10-30 08:31:07 +01:00

In #69992#803121, @Voronium wrote:
As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it:

Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...)

Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state.

This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool.

ˆ definitely +1

> In #69992#803121, @Voronium wrote: > As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it: > 1) Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...) > 2) Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state. > > This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool. ˆ definitely +1

Campbell Barton commented

2019-10-30 08:47:27 +01:00

@Voronium this requires changes to the event system, see D5153: Event system & keymap support for key detecting/ignoring key repeat events

Although there are implications for pressing other keys while a modal operator runs. G,X,2 currently moves 2 on the X axis... it could be made to work I couldn't think of solutions that didn't feel kludgy.

@Voronium this requires changes to the event system, see [D5153: Event system & keymap support for key detecting/ignoring key repeat events](https://archive.blender.org/developer/D5153) Although there are implications for pressing other keys while a modal operator runs. `G,X,2` currently moves 2 on the X axis... it could be made to work I couldn't think of solutions that didn't feel kludgy.

David Friedli commented

2019-10-30 09:09:21 +01:00

In #69992#803121, @Voronium wrote:
As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it:

Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...)

Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state.

This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool.

I thoght about that as well and it's definitely an interesting approach. One downside i see is that it might be awkward to change operator settings (like axis constraining) while holding a key. The proposal i wrote a bit further up the comments section is similar but relies on the given selection instead of key-hold events.

Anyway in the long run i think it's important to unify the two systems and not just giving the user the possibility to access both tools and operators. Otherwise there will always be the potential for inconsistentcies between every tool-operator pair.

> In #69992#803121, @Voronium wrote: > As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it: > 1) Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...) > 2) Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state. > > This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool. I thoght about that as well and it's definitely an interesting approach. One downside i see is that it might be awkward to change operator settings (like axis constraining) while holding a key. The proposal i wrote a bit further up the comments section is similar but relies on the given selection instead of key-hold events. Anyway in the long run i think it's important to unify the two systems and not just giving the user the possibility to access both tools and operators. Otherwise there will always be the potential for inconsistentcies between every tool-operator pair.

Pieter Schiettecatte commented

2019-10-30 18:25:28 +01:00

Added subscriber: @Schiette

Pieter Schiettecatte commented

2019-10-30 18:25:28 +01:00

As a new user starting to learn Blender, I have found the difference between the 'gizmo move tool' vs the 'G move shortcut' for example confusing.

This proposal (alt as a leader key) does add shortcuts to the gizmo, but it doesn't address the underlying problem. I think you could argue that this design makes the program more complicated. A more elegant solution would be to merge the gizmo tools with the traditional transform operators.

As a new user starting to learn Blender, I have found the difference between the 'gizmo move tool' vs the 'G move shortcut' for example confusing. This proposal (alt as a leader key) does add shortcuts to the gizmo, but it doesn't address the underlying problem. I think you could argue that this design makes the program more complicated. A more elegant solution would be to merge the gizmo tools with the traditional transform operators.

William Reynish commented

2019-10-30 18:57:28 +01:00

There’s a very easy way to ‘merge’ them. Make the shortcuts change the active tool, rather than the modal operator. But I suspect some users won’t want that.

Pieter Schiettecatte commented

2019-10-30 19:10:57 +01:00

One way you could look at it is that there's one command (grab) that exists in two flavors: active tool (with the gizmo) and modal.

What if there was a shortcut to switch between modal / gizmo after triggering the grab. It would be especially helpful if it remembered that setting.

If you prefer the modal ones, nothing has to change.
If you like the gizmo's, you just switch to the gizmo when using the tool for the first time, and it will be remembered from then on.
If you like to alternate between modal and active tools, you can use the hotkey after activating a command

I should stress that I haven't been using blender for long so there's a good chance this proposal has severe downsides and/or is unrealistic :)

One way you could look at it is that there's one command (grab) that exists in two flavors: active tool (with the gizmo) and modal. What if there was a shortcut to switch between modal / gizmo after triggering the grab. It would be especially helpful if it remembered that setting. - If you prefer the modal ones, nothing has to change. - If you like the gizmo's, you just switch to the gizmo when using the tool for the first time, and it will be remembered from then on. - If you like to alternate between modal and active tools, you can use the hotkey after activating a command I should stress that I haven't been using blender for long so there's a good chance this proposal has severe downsides and/or is unrealistic :)

mankysee commented

2019-10-30 19:19:38 +01:00

In #69992#803523, @WilliamReynish wrote:
There’s a very easy way to ‘merge’ them. Make the shortcuts change the active tool, rather than the modal operator. But I suspect some users won’t want that.

that's not really merging since these tools and operators have somehow different additional functionality. But for g/r/s tools I've actually done that since for me it's easier to get visual feedback instead of keeping all of the gizmos on all the time.

In #69992#803539, @Schiette wrote:
One way you could look at it is that there's one command (grab) that exists in two flavors: active tool (with the gizmo) and modal.

What if there was a shortcut to switch between modal / gizmo after triggering the grab. It would be especially helpful if it remembered that setting.

If you prefer the modal ones, nothing has to change.

If you like the gizmo's, you just switch to the gizmo when using the tool for the first time, and it will be remembered from then on.

If you like to alternate between modal and active tools, you can use the hotkey after activating a command

I should stress that I haven't been using blender for long so there's a good chance this proposal has severe downsides and/or is unrealistic :)

I am a somehow power user and I do like your idea a lot.

> In #69992#803523, @WilliamReynish wrote: > There’s a very easy way to ‘merge’ them. Make the shortcuts change the active tool, rather than the modal operator. But I suspect some users won’t want that. that's not really merging since these tools and operators have somehow different additional functionality. But for g/r/s tools I've actually done that since for me it's easier to get visual feedback instead of keeping all of the gizmos on all the time. > In #69992#803539, @Schiette wrote: > One way you could look at it is that there's one command (grab) that exists in two flavors: active tool (with the gizmo) and modal. > > What if there was a shortcut to switch between modal / gizmo after triggering the grab. It would be especially helpful if it remembered that setting. > > - If you prefer the modal ones, nothing has to change. > - If you like the gizmo's, you just switch to the gizmo when using the tool for the first time, and it will be remembered from then on. > - If you like to alternate between modal and active tools, you can use the hotkey after activating a command > > I should stress that I haven't been using blender for long so there's a good chance this proposal has severe downsides and/or is unrealistic :) I am a somehow power user and I do like your idea a lot.

Campbell Barton commented

2019-10-30 19:38:10 +01:00

In #69992#803523, @WilliamReynish wrote:
There’s a very easy way to ‘merge’ them. Make the shortcuts change the active tool, rather than the modal operator. But I suspect some users won’t want that.

You need a way to access text input during transform, bevel, etc or, remove this feature which is a bigger change.

> In #69992#803523, @WilliamReynish wrote: > There’s a very easy way to ‘merge’ them. Make the shortcuts change the active tool, rather than the modal operator. But I suspect some users won’t want that. You need a way to access text input during transform, bevel, etc or, remove this feature which is a bigger change.

William Reynish commented

2019-10-30 19:47:38 +01:00

@ideasman42 I am not necessarily proposing that. Just merely explaining why they aren't 'merged' so to speak.

CobraA commented

2019-10-31 01:09:16 +01:00

Added subscriber: @CobraA

CobraA commented

2019-10-31 01:09:16 +01:00

I too don't like this, it adds an extra complexity and causes confusion with the clear transform operations..., and like what the others have said, we got the toolbar shortcut. better work on improving that imo.
PS: can we disable this option completely? for us who won't use it.

I too don't like this, it adds an extra complexity and causes confusion with the clear transform operations..., and like what the others have said, we got the toolbar shortcut. better work on improving that imo. PS: can we disable this option completely? for us who won't use it.

Stanislav Blinov commented

2019-11-07 09:45:44 +01:00

Added subscriber: @Stan_Pancakes

Stanislav Blinov commented

2019-11-07 09:45:44 +01:00

IMHO, this is a mis-feature at this point. The first thought when seeing this in 2.82 for the first time was "no, no way in hell". And I'm a vim user.

The (shift) spacebar menu already achieves similar functionality, and the argument that "it's not a shortcut because it shows a menu" just doesn't make any sense. There are tons of shortcuts in Blender that do just that, one of the most prominent examples being the X key. Alt, g or space, g is the same two finger motions. No. Difference. At. All. When one knows the shortcut already, they'd press it. When not, they'll look for the hint. In fact, popping it up in a menu where user's eyes are already looking is far more helpful, for obvious reasons. Moreover, status text simply doesn't fit the width (e.g. edit mode with current implementation of this... "feature": on a 1920 display it ends with Alt-S, not even showing what that key does). Moreover, this approach creates ambiguity. For example, with the Alt key as leader by default, in edit mode Alt, e will do a different thing compared to Alt+e, and since it's far less apparent (because the "hint" is down there, not where the eyes are), it's going to create confusion.

A far better approach, IMHO, is to allow easier customization of tool keys, e.g. to make the frequently-used tools (by a given person) more accessible via existing means (the spacebar menu).

How many input paradigms are there at this point? We have shortcuts, shortcuts that call menus, pie menus, pie menus with regular menus in them, menus on press, menus on hold... Now this.

Lastly, as @CobraA suggests, if this... thing does end up in Blender, it absolutely must be disabled by default. It will just confuse new users who will undoubtedly be hitting the "leader" at a regular basis and tripping up on unexpected actions.

IMHO, this is a mis-feature at this point. The first thought when seeing this in 2.82 for the first time was "no, no way in hell". And I'm a vim user. The (shift) spacebar menu already achieves similar functionality, and the argument that "it's not a shortcut because it shows a menu" just doesn't make any sense. There are **tons** of shortcuts in Blender that do just that, one of the most prominent examples being the X key. Alt, g or space, g is the same two finger motions. No. Difference. At. All. When one knows the shortcut already, they'd press it. When not, they'll look for the hint. In fact, popping it up in a menu where user's eyes **are already looking** is far more helpful, for obvious reasons. Moreover, status text simply doesn't fit the width (e.g. edit mode with current implementation of this... "feature": on a 1920 display it ends with Alt-S, not even showing what that key does). Moreover, this approach creates ambiguity. For example, with the Alt key as leader by default, in edit mode Alt, e will do a different thing compared to Alt+e, and since it's far less apparent (because the "hint" is down there, not where the eyes are), it's going to create confusion. A far better approach, IMHO, is to allow easier customization of tool keys, e.g. to make the frequently-used tools (by a given person) more accessible via existing means (the spacebar menu). How many input paradigms are there at this point? We have shortcuts, shortcuts that call menus, pie menus, pie menus with regular menus in them, menus on press, menus on hold... Now this. Lastly, as @CobraA suggests, if this... thing does end up in Blender, it absolutely must be disabled by default. It will just confuse new users who will undoubtedly be hitting the "leader" at a regular basis and tripping up on unexpected actions.

Ray Mairlot commented

2019-11-11 15:07:55 +01:00

Added subscriber: @RayMairlot

Fran Marz commented

2019-11-27 13:59:09 +01:00

Added subscriber: @franMarz

Fran Marz commented

2019-11-27 13:59:09 +01:00

I don't find an option to disable the leader-key in the preferences, or change it. Am I missing it, or is it planned?
I have a lot of key-bindings that include the Alt key (for modeling, orbiting) and I'm experiencing undesirable switches to different tools fairly often.

I don't find an option to disable the leader-key in the preferences, or change it. Am I missing it, or is it planned? I have a lot of key-bindings that include the Alt key (for modeling, orbiting) and I'm experiencing undesirable switches to different tools fairly often.

Konstantina Anagnostou commented

2019-12-22 16:04:43 +01:00

Added subscriber: @Constantina32

Stanislav Blinov commented

2020-01-01 14:07:42 +01:00

Some feedback after testing this on recent builds (I still think it's a feature that doesn't need to exist, but since it's already here, might as well at least help improve it):

It seems to not take well to key conflicts, although that may be more of a failure of the tool system in general. For example, in the keymap for Mesh, I've rebound the 't' key to Inset Faces. So now when I press t in edit mode I instantly activate the Inset modal operator (easier to reach with left hand than the default 'i' key). But, 't' is also bound to the Transform tool, so both in the Tools menu, and in this new prompt, the Transform and Inset both now list the 'T' key as shortcut, and since the Transform comes before Inset, the alt, t sequence activates Transform tool, instead of Inset.
I can "lose" tools when unbound in keymap. I've unbound the 'B' key in the keymap, since it's redundant in 2.8x. For the Tools menu, this resulted in Select Box tool being available via the '2' key. But with this new prompt, it would seem that made the tool inaccessible altogether - it's not listed in the prompt at all.

Some feedback after testing this on recent builds (I still think it's a feature that doesn't need to exist, but since it's already here, might as well at least help improve it): 1) It seems to not take well to key conflicts, although that may be more of a failure of the tool system in general. For example, in the keymap for Mesh, I've rebound the 't' key to Inset Faces. So now when I press t in edit mode I instantly activate the Inset modal operator (easier to reach with left hand than the default 'i' key). But, 't' is also bound to the Transform tool, so both in the Tools menu, and in this new prompt, the Transform and Inset both now list the 'T' key as shortcut, and since the Transform comes before Inset, the alt, t sequence activates Transform tool, instead of Inset. 2) I can "lose" tools when unbound in keymap. I've unbound the 'B' key in the keymap, since it's redundant in 2.8x. For the Tools menu, this resulted in Select Box tool being available via the '2' key. But with this new prompt, it would seem that made the tool inaccessible altogether - it's not listed in the prompt at all.

Ray Mairlot commented

2020-01-01 17:42:54 +01:00

Removed subscriber: @RayMairlot

CobraA commented

2020-01-15 00:11:59 +01:00

I found how to disable it, search "wm.toolbar_prompt" in the input editor and disable toolbar prompt for both left/right Alt.

Yevgeny Makarov commented

2020-01-30 12:01:18 +01:00

Added subscriber: @jenkm

Yevgeny Makarov commented

2020-01-30 12:01:18 +01:00

@ideasman42 @WilliamReynish

There are currently some issues.

First, trying to "Rotate View" using the Trackpad Pan and "Zoom" with the Cmd + Trackpad Pan will not cancel the leader keys prompt.

Second, say I'm going to press Alt+D, I press and hold Alt, and suddenly I realize I need Shift+D, I release Alt, and then I can't press Shift+D right away.
So, the leader keys should be activated only by short tapping, but not holding, at least if the Alt/Shift/Ctrl is used as a modifier.

@ideasman42 @WilliamReynish There are currently some issues. First, trying to "Rotate View" using the `Trackpad Pan` and "Zoom" with the `Cmd + Trackpad Pan` will not cancel the leader keys prompt. Second, say I'm going to press `Alt+D`, I press and hold `Alt`, and suddenly I realize I need `Shift+D`, I release `Alt`, and then I can't press `Shift+D` right away. So, the leader keys should be activated only by **short tapping**, but not holding, at least if the Alt/Shift/Ctrl is used as a modifier.

Fran Marz commented

2020-01-31 10:29:15 +01:00

Removed subscriber: @franMarz

Stanislav Blinov commented

2020-03-04 12:03:40 +01:00

Why is this enabled by default? Why is this not mentioned in release notes?

Mobin commented

2020-03-04 14:10:18 +01:00

Added subscriber: @Mobin-2

Mobin commented

2020-03-04 14:10:18 +01:00

conflicts with emulate 3 button mouse. had to disable the keybinding for this feature to get a reliable emulate 3 button mouse while working.

Dong-Hyun Kim commented

2020-03-16 15:07:46 +01:00

Added subscriber: @temeddix

Dong-Hyun Kim commented

2020-03-16 15:15:15 +01:00

In #69992#803121, @Voronium wrote:
As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it:

Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...)

Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state.

This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool.

+1 for this idea!

Maybe this is the cleanest solution we can achieve. This satisfies both the tool system and the existing users(though now they would need to long-press G/R/S). Now that tool gizmos are complete and selection method got significant improvements(with fallback tools) in 2.82, the only thing left is to apply G/R/S/K/E...to these tools, while long-press leads to operators(just like short-click used to do).

Furthurmore the long-press hotkey concept has a huge potential for other operations as well(i.e. long-press tab for object mode pie-menus)

Wouldn't changing the event handler be worth the effort?

> In #69992#803121, @Voronium wrote: > As an ex-Softimage user I would like to propose a slightly different solution as I believe was very cleverly implemented in it: > 1) Taping on a shortcut key ( G, S, R, ...) activate the Tool (Move, Scale, Rotate, ...) > 2) Pressing and holding (!) the same key temporary activate the Operator (Move, Scale, Rotate ...) and releasing the key returns the tool/operator to it's previous state. > > This way, if for example, we are are using the Move tool to arrange our scene, but we need a quick scale of an object, we press and hold "S" to do the job and when we release it we automatically continue with the Move tool. +1 for this idea! Maybe this is the cleanest solution we can achieve. This satisfies both the tool system and the existing users(though now they would need to **long-press** G/R/S). Now that tool gizmos are complete and selection method got significant improvements(with fallback tools) in 2.82, the only thing left is to apply G/R/S/K/E...to these **tools**, while **long-press** leads to **operators**(just like **short-click** used to do). Furthurmore the **long-press hotkey** concept has a huge potential for other operations as well(i.e. long-press tab for object mode pie-menus) Wouldn't changing the event handler be worth the effort?

Paul Kotelevets commented

2020-06-13 08:39:47 +02:00

Added subscriber: @1D_Inc

Paul Kotelevets commented

2020-06-13 08:39:47 +02:00

In #69992#803128, @ideasman42 wrote:
Although there are implications for pressing other keys while a modal operator runs. G,X,2 currently moves 2 on the X axis... it could be made to work I couldn't think of solutions that didn't feel kludgy.

That's correct.
Key-based (two hands no gizmo) modal operators workflow have a goal to be fastest, because it is used for intensive work, while tool-based (one-hand gizmo-related) slow workflow better fits learning process, lowering entry threshold.
Current solution keeps speed-related G.E.A.R.S. workflow fast.

> In #69992#803128, @ideasman42 wrote: > Although there are implications for pressing other keys while a modal operator runs. `G,X,2` currently moves 2 on the X axis... it could be made to work I couldn't think of solutions that didn't feel kludgy. That's correct. Key-based (two hands no gizmo) modal operators workflow have a goal to be fastest, because it is used for intensive work, while tool-based (one-hand gizmo-related) slow workflow better fits learning process, lowering entry threshold. Current solution keeps speed-related G.E.A.R.S. workflow fast.

Evan Wilson commented

2020-07-17 18:59:24 +02:00

Added subscriber: @EAW

Evan Wilson commented

2020-07-17 18:59:24 +02:00

Keymap: disable 'Alt' click for tools prompt by default
Based on feedback from artists in the Blender Studio this is too
easy to access by accident.
This is still accessible as a preference.

279cc34343

This change should be in the release notes, otherwise bug reports will most likely be filed about how it "missing."

>**Keymap: disable 'Alt' click for tools prompt by default** >Based on feedback from artists in the Blender Studio this is too >easy to access by accident. >This is still accessible as a preference. 279cc34343 This change should be in the release notes, otherwise bug reports will most likely be filed about how it "missing."

Philipp Oeser removed the

Interest

User Interface

label 2023-02-10 09:25:08 +01:00

Sign in to join this conversation.

28 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#69992

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Shortcuts for Tools (design task) #69992

Leader Keys

Visual Feedback

Implementation

Precedents

trigger a modal operator

activating a tool with its gizmos