Revert view menu pie keybinding change and put Transfer Mode on Alt+Q #89757

New Issue

Sebastian Parborg · 2021-07-09T12:44:32+02:00

Sebastian Parborg commented

2021-07-09 12:44:32 +02:00

After some longer discussion in the UI module, we came to the conclusion to revert the view map pie menu shortcut to the tilde key (on US layout keyboards) and put the Transfer Mode operator shortcut on Alt+Q.

This is because having the View map pie menu on the D key while simultaneously having it act as an annotate shortcut lead to very frustrating situations where the users could constantly be triggering the pie menu by mistake.

The pie menu was moved to the D key so Transfer Mode could take it's place.
However the key is not available on quite a few keyboard layouts as we don't properly support non US layouts in blender yet.

Therefore it was decided to move this new keybinding to Alt+Q instead and revert the view pie menu change.

While this might leave some users unable to access the pie menu, we have multiple other ways to quickly change the orientation of the viewport. However I think we should work towards making sure that there are no "dead keys" on non US layouts moving forward to solve this issue. But that is for an other task/project.

See: #88092 (Keymap: use D-key for view navigation pie-menu (2nd iteration)) for the task that proposed this change.

After some longer discussion in the UI module, we came to the conclusion to revert the view map pie menu shortcut to the tilde key (on US layout keyboards) and put the `Transfer Mode` operator shortcut on Alt+Q. This is because having the View map pie menu on the `D` key while simultaneously having it act as an annotate shortcut lead to very frustrating situations where the users could constantly be triggering the pie menu by mistake. The pie menu was moved to the `D` key so `Transfer Mode` could take it's place. However the key is not available on quite a few keyboard layouts as we don't properly support non US layouts in blender yet. Therefore it was decided to move this new keybinding to `Alt+Q` instead and revert the view pie menu change. While this might leave some users unable to access the pie menu, we have multiple other ways to quickly change the orientation of the viewport. However I think we should work towards making sure that there are no "dead keys" on non US layouts moving forward to solve this issue. But that is for an other task/project. --- See: #88092 (Keymap: use D-key for view navigation pie-menu (2nd iteration)) for the task that proposed this change.

Sebastian Parborg commented

2021-07-09 12:44:32 +02:00

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

Sebastian Parborg commented

2021-07-09 12:44:32 +02:00

Added subscriber: @ZedDB

Campbell Barton commented

2021-07-09 13:51:51 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2021-07-09 13:51:51 +02:00

If others are fine with this change, this seems I'm OK to make this although I think it's unfortunate that we couldn't make the view pie more accessible.

Notes:

I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. (the option to switch between these two could be a preference).
From discussion on-line we could shuffle key bindings to use Shift-Tab for Transfer Mode, but this would lead to re-assigning snap toggle, and doesn't resolve the D-key conflict.
Spending time to ensure the key located to the left of 1 (~ on a US-english keyboard) is reliably mapped to the view menu could resolve the remapping that moving this to the D-key originally was intended to solve.

If others are fine with this change, this seems I'm OK to make this although I think it's unfortunate that we couldn't make the view pie more accessible. --- **Notes:** - I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. *(the option to switch between these two could be a preference).* - From discussion on-line we could shuffle key bindings to use Shift-Tab for `Transfer Mode`, but this would lead to re-assigning snap toggle, and doesn't resolve the D-key conflict. - Spending time to ensure the key located to the left of `1` (`~` on a US-english keyboard) is reliably mapped to the view menu could resolve the remapping that moving this to the D-key originally was intended to solve.

Pablo Dobarro commented

2021-07-09 17:39:25 +02:00

Added subscriber: @PabloDobarro

Pablo Dobarro commented

2021-07-09 17:39:25 +02:00

One of the concerns with the initial solution of having ##D## for ##Transfer Mode## is that it does not have relation with the selection operation. The new shortcut is even less discoverable, so we should consider it as the best solution we can have right now, but not the final one. The main issue is that the paint modes capture all mouse click events for the ##paint_stroke## operator, so ##Transfer Mode## can't be assigned to any event which consist in a click + modifier key.
This could be properly supported if we had a way to make ##stroke_paint## to always start painting in mouse drag while still getting the click event to get the orientation of the brush tip in the second stroke sample.

I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. (the option to switch between these two could be a preference).

I agree with this. The ##D## key is an accesible key that will be available in any keyboard layout which by default has assigned functionality that is redundant with the tool system. Then we can discuss which functionality we map to ##D##, which could be a pie menu, ##Transfer Mode##, or any other important action that is not easily accesible in any other way.

One of the concerns with the initial solution of having ##D## for ##Transfer Mode## is that it does not have relation with the selection operation. The new shortcut is even less discoverable, so we should consider it as the best solution we can have right now, but not the final one. The main issue is that the paint modes capture all mouse click events for the ##paint_stroke## operator, so ##Transfer Mode## can't be assigned to any event which consist in a click + modifier key. This could be properly supported if we had a way to make ##stroke_paint## to always start painting in mouse drag while still getting the click event to get the orientation of the brush tip in the second stroke sample. > I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. (the option to switch between these two could be a preference). I agree with this. The ##D## key is an accesible key that will be available in any keyboard layout which by default has assigned functionality that is redundant with the tool system. Then we can discuss which functionality we map to ##D##, which could be a pie menu, ##Transfer Mode##, or any other important action that is not easily accesible in any other way.

Sebastian Parborg commented

2021-07-12 11:51:58 +02:00

I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. (the option to switch between these two could be a preference).

I think it would be better to first fix our "dead keys" issue and expand the functionality of our keybinding system.

This is because a lot of workflows are not tool centric and having a key on the home row for that would be quite wasteful in those scenarios.
The reverse is true as well of course.

I very much think we should first work on the basics and clean up both the UI and code of the keymap.
This way we will hopefully empower the users to easily switch between different presets and customize them.

At least my current experience with the studio tells me that a lot of people don't do this because of lacking presentation and that their keymap regularly gets trashed between releases.

So at least to me I feel that we should get the basics right before we start changing around the default keymap to accommodate specific workflows.

> I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. (the option to switch between these two could be a preference). I think it would be better to first fix our "dead keys" issue and expand the functionality of our keybinding system. This is because a lot of workflows are not tool centric and having a key on the home row for that would be quite wasteful in those scenarios. The reverse is true as well of course. I very much think we should first work on the basics and clean up both the UI and code of the keymap. This way we will hopefully empower the users to easily switch between different presets and customize them. At least my current experience with the studio tells me that a lot of people don't do this because of lacking presentation and that their keymap regularly gets trashed between releases. So at least to me I feel that we should get the basics right before we start changing around the default keymap to accommodate specific workflows.

Campbell Barton commented

2021-07-15 12:10:34 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2021-07-15 12:10:34 +02:00

Campbell Barton self-assigned this 2021-07-15 12:10:34 +02:00

Campbell Barton commented

2021-07-15 12:10:35 +02:00

Resolved c614eadb47

Resolved c614eadb47

michael knubben commented

2021-07-20 12:26:41 +02:00

Added subscriber: @michaelknubben

michael knubben commented

2021-07-20 12:26:41 +02:00

In #89757#1189205, @ideasman42 wrote:

I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. (the option to switch between these two could be a preference).

Please don't. For something that's used to quickly and often only for a second or so, switching to the tool is just a hassle. It being the same in all of Blender, including Shader Editor etc is a massive boon to users

> In #89757#1189205, @ideasman42 wrote: > - I'd consider removing annotations from the D key and making this accessible only by tools-system. Although this wouldn't be popular with people who use annotations frequently, it's a trade-off. *(the option to switch between these two could be a preference).* Please don't. For something that's used to quickly and often only for a second or so, switching to the tool is just a hassle. It being the same in all of Blender, including Shader Editor etc is a massive boon to users

Sign in to join this conversation.

4 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#89757

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Revert view menu pie keybinding change and put Transfer Mode on Alt+Q #89757